Practitioner's Docket No. D1077+08 PATENT 
IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

Box Patent Application . ^ g 

Assistant Commissioner for Patents ^ ^ 



Washington, D.C. 20231 



NEW APPLICATION TRANSMITTAL 



OJO\ 



Transmitted herewith for filing is the patent application of 

Inventor(s): Jay Paul Drummond, Dale Blackson, Bob A. Cichon, Joseph C. Ess, Mark S. Covert, Mark 
A. Moales, David W* Weis, Mark D. Smith, Bruce G. Richards, James Church 



WARNING: 37 CFR L4J(a)(J) points out: 

"(a) A patent is applied for in the name or names of the actual inventor or inventors, 

(}) The inventorship of a nonprovisionaJ application is that inventorship set forth in the oath or declaration 
as prescribed by § L 63, except as provided for dn § I:^3(d)(4) and § 1.63(d). If an oath or declaration as prescribed 
by § L63 is not filed during the pendency ofqnonprovisional application, the inventorship is that inventorship set 
forth in the application papers filed pursuant to § L53(b), unless a petition under this paragraph accompanied by the 
fee set forth in § L 1 7(i) is filed supplying or changing the name or names of the inventor or inventors. " 



For (title): AUTOMATED BANKING MACHINE APPARATUS AND SYSTEM 

CERTIFICATION UNDER 37 C.r.R. 1.10* 

(Express Mail label number is mandatory.) 
(Express Mail certification is optional.) 

I hereby certify that this correspondence and the documents referred to as attached therein are being deposited with the United 
States Postal Service on this date in an envelope as "Express Mail Post Office to Addressee," maihng 

Label Nnmhen ^/ . addressed to the: Assistant Commissioner for Patents, Washington, D.C. 20231. 

Ralph E. Jocke , 

(type or print name of person mailing paper) 

WARNING: Certificate of mailing (first class) or facsimile transmission procedures of 37 C.KR. 1.8 cannot be used to 
obtain a date of mailing or transmission for this correspondence. 

^WARNING: Each paper or fee filed by "Express Mail" must have the number of the ''Express Mail" mailing label 
placed thereon prior to mailing. 37 C.F.R. 1.10(b). 

"Since the filing of correspondence under § 1. 10 without the Express Mail mailing label thereon is an 
oversight that can be avoided by the exercise of reasonable care, requests for waiver of this requirement will 
not be granted on petition. " Notice of Oct. 24, 1996, 60 Fed Reg 56,439, at 56,442. 
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1 . Type of Application 



This new application is for a(n) 



(check one applicable item below) 



[X] Original (nonprovisional) 
[ ] Design 
[ ] Plant 

WARNING: Do not use this transmittal for a completion in the U,S. of an International Application under 35 U.S.C 

371(c)(4), unless the International Application is being filed as a divisional, continuation or continuation-in- 
part application, 

WARNING: Do not use this transmittal for the filing of a provisional application, 

NOTE' If one of the following 3 items apply, then complete and attach ADDED PAGES FOR NEW APPLICATION 

TRANSMITTAL WHERE BENEFIT OF A PRIOR U.S, APPLICATION CLAIMED and a NOTIFICA TION IN PARENT 
APPLICATION OF THE FILING OF THIS CONTINUATION APPLICATION 



[ ] Divisional. 

[ ] Continuation. 

[X] Continuation-in-part (C-I-P). 



2. Benefit of Prior U.S. Application(s) (35 U.S.C. 1 19(eX 120, or 121) 

NOTE: A nonprovisional application may claim an invention disclosed in one or more prior filed copending nonprovisional 
applications or copending international applications designating the United States of America, In order for a 
nonprovisional application to claim the benefit of a prior filed copending nonprovisional application or copending 
international application designating the United States of America, each prior application must name as an inventor 
at least one inventor named in the later filed nonprovisional application and disclose the named inventor *s invention 
claimed in at least one claim of the later filed nonprovisional application in the manner provided by the first 
paragraph of 35 US.C. 112, Each prior application must also be: 

(i) An international application entitled to a filing date in accordance with PCT Article 1 1 and designating 
the United States of America; or 

(it) Complete as set forth in § L5I(b); or 

(Hi) Entitled to a filing date as set forth in § L53(b) or § L53(d) and include the basic filing fee set forth in § 
Li 6; or 

(iv) Entitled to a filing date as set forth in § 1, 53(b) and have paid therein the processing and retention fee 
set forth in § 1.21(1) within the time period set forth in § L53(fi, 

37 CFRI. 78(a)(1). 

NOTE If the new application being transmitted is a divisional continuation or a continuation-in-part of a parent case, or 
where the parent case is an International Application which designated the US, or benefit of a prior provisional 
application is claimed, then check the following item and complete and attach ADDED PAGES FOR NEW 
APPLICATION TRANSMITTAL WHERE BENEFIT OF PRIOR US APPLICATION (S) CLAIMED. 

WARNING: If an application claims the benefit of the filing date of an earlier filed application under 35 US C 120, 121 
or 365(c), the 20-year term of that application will be based upon the filing date of the earliest US. 
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application that the application makes reference to under 35 U,S.C, 120, 121 or 365(c). (35 U.S.C 154(a)(2) 
does not take into account, for the determination of the patent term, any application on which priority is 
claimed under 35 U.S.C 119, 365(a) or 365(b).) For a c-i-p application, applicant should review whether 
any claim in the patent that will issue is supported by an earlier application and, if not, the applicant should 
consider canceling the reference to the earlier fded application. The term of a patent is not based on a 
claim-by-claim approach. See Notice of April 14, 1995, 60 Fed Reg. 20,195, at 20,205. 

When the last day of pendency of a provisional application falls on a Saturday, Sunday, or Federal holiday 
within the District of Columbia, any nonprovisional application claiming benefit of the provisional 
application must be filed prior to the Saturday, Sunday, or Federal holiday within the District of Columbia. 
See 37 CFR.§ 1.78(a)(3). 

The new application being transmitted claims the benefit of prior U.S. application(s). 
Enclosed are ADDED PAGES FOR NEW APPLICATION TRANSMITTAL WHERE 
BENEFIT OF PRIOR U.S. APPLICATION(S) CLAIMED. 



3, Papers Enclosed 

A. Required for Filing Date under 37 C.F.R. L53(b) (Regular) or 37 C.F.R, 1.153 
(Design) Application 

78 Pages of Specification 
7 Pages of Claims 
31 Sheets of Drawing 

[ ] Formal 

[X] Informal 

B. Other Papers Enclosed 

1 Pages of Abstract 
Other 



WARNING: DO NOT submit original drawings. A high quality copy of the drawings should be supplied when filing a 

patent application. The drawings that are submitted to the Office must be on strong, white, smooth, and non- 
shiny paper and meet the standards according to § 1.84, If corrections to the drawings are necessary, they 
should be made to the original drawing and a high-quality copy of the corrected original drawing then 
submitted to the Office. Only one copy is required or desired. For comments on proposed then-new 3 7 
CF.R. 1.84, see Notice of March 9, 1988 . . . (1990 O.G. 57-62). 

NOTE: "Identifying indicia, if provided, should include the application number or the title of the invention, inventor's name, 
docket number (if any), and the name and telephone number of a person to call if the Office is unable to match the 
drawings to the proper application. This information should be placed on the back of each sheet of drawing a 
minimum distance of 1.5 cm. (5/8 inch) down from the top of the page. " 37 CF.R. 1. 84(c)). 

(complete the following, if applicable) 

[ ] The enclosed drawing(s) are photograph(s), and there is also attached a "PETITION TO 
ACCEPT PHOTOGRAPH(S) AS DRAWING(S)." 37 CF.R. L84(b). 



WARNING: 
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4. Additional Papers Enclosed 

[ ] Preliminary Amendment 

[ ] Information Disclosure Statement (37 C.F.R. 1.98) 
[ ] Form PTO-1449 (PTO/SB/08A and 08B) 
[ ] Citations 

[ ] Declaration of Biological Deposit 

[ ] Submission of "Sequence Listing " computer readable copy and/or amendment pertaining 

thereto for biotechnology invention containing nucleotide and/or amino acid sequence. 
[ ] Authorization of Attomey(s) to Accept and Follow Instructions from Representative 
[ ] Special Comments 
f 1 Other 



5. Declaration or Oath 

NOTE: A newly executed declaration is not required in a continuation or divisional application provided the prior 

nonprovisional application contained a declaration as required, the application being filed is by all or fewer than all 
the inventors named in the prior application, there is no new matter in the application being fded, and a copy of the 
executed declaration filed in the prior application (showing the signature or an indication thereon that it was signed) 
is submitted. The copy must be accompanied by a statement requesting deletion of the names ofperson(s) who are not 
inventors of the application being filed If the declaration in the prior application was filed under § 1.47 then a copy 
of that declaration must be filed accompanied by a copy of the decision granting § L47 status or, if a nonsigning 
person under § 1 .41 has subsequently joined in a prior application, then a copy of the subsequently executed 
declaration must be filed. See 37 CFR 1.63(d). 

NOTE: A declaration filed to complete an application must be executed, identify the specification to which it is directed, 
identify each inventor by full name, including the family name, and at least one given name without abbreviation 
together with any other given name or initial, and the residence, post office address and country of citizenship of each 
inventor and state whether the inventor is a sole or joint inventor. 37 CFR L63(a)(l)-(4). 



[ ] Enclosed 

Executed by 

(check all applicable boxes) 

[ ] inventor(s). 

[ ] legal representative of inventor(s). 37 CFR 1 .42 or 1 .43. 
[ ] joint inventor or person showing a proprietary interest on behalf of inventor who 
refused to sign or cannot be reached. 

[ ] This is the petition required by 37 CFR 1 .47 and the statement required 
by 37 CFR 1.47 is also attached. See item 13 below for fee. 

[X] Not Enclosed. 

NOTE: Where the filing is a completion in the U.S. of an International Application, or where the completion of the U.S. 

application contains subject matter in addition to the International Application, the application may be treated as a 
continuation or continuation-in-part, as the case may be, utilizing ADDED PAGE FOR NEW APPLICATION 
TRANSMITTAL WHERE BENEFIT OF PRIOR U.S APPLICATION CLAIMED. 

[ ] Application is made by a person authorized under 37 C.F.R, 1.41(c) on behalf of 
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all the above named inventor(s). 

(The declaration or oath, along with the surcharge required by 37 CFR L 16(e), 

can be filed subsequently). 

NOTE: It is important that all the correct inventor(s) are named for filing under 37 CFR L41(c) and L53(b). 

[ ] Showing that the filing is authorized. 

(not required unless called into question. 37 CFR 1.41 (d)) 



6. Inventorship Statement 

WARNING: If the named inventors are each not the inventors of all the claims an explanation, including the ownership 
of the various claims at the time the last claimed invention was made, should be submitted. 

The inventorship for all the claims in this application are: 

[X] The same. 

or 

[ ] Not the same. An explanation, including the ownership of the various claims at the time 
the last claimed invention was made, 
[ ] is submitted. 
[ ] will be submitted. 



7. Language 

NOTE: An application including a signed oath or declaration may be filed in a language other than English. An English 

translation of the non-English language application and the processing fee of $130.00 required by 37 CFR L 1 7(k) is 
required to be filed with the application, or within such time as may be set by the Office, 37 CFR J .52(d). 

[X] English 

[ ] Non-English 

[ ] The attached translation includes a statement that the translation is accurate. 37 
C.F.R. 1.52(d). 
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8. Assignment 

[X] An assignment of the invention to Diebold Incorporated 



[ ] is attached. A separate [ ] "COVER SHEET FOR ASSIGNMENT (DOCU- 
MENT) ACCOMPANYESfG NEW PATENT APPLICATION" or [ ] FORM 
PTO 1595 is also attached. 

[X] will follow. 

NOTE: ''If an assignment is submitted with a new application, send two separate letters-one for the application and one for 
the assignment" Notice of May 4, 1990 (JIM O.G. 77-78). 

WARNING: A newly executed "STATEMENT UNDER 37 CFR 3, 73(b) " must be filed when a continuation-in-part 
application is filed by an assignee. Notice of April 30, 1993, 1 1 50 O.G. 62-64. 



9. 


Certified Copy 

Certified copy(ies) of application(s) 








Country 


Appln. no. 


Filed 




Country 


Appln. no. 


Filed 




Country 


Appln. no. 


Filed 



from which priority is claimed 
[ ] is (are) attached. 
[ ] will follow. 

NOTE: The foreign application forming the basis for the claim for priority must be referred to in the oath or declaration. 3 7 
CFR L55(a) and L63, 

NOTE: This item is for any foreign priority for which the application being filed directly relates. If any parent U.S. 

application or International Application from which this application claims benefit under 35 US.C. 120 is itself 
entitled to priority from a prior foreign application, then complete item 18 on the ADDED PAGES FOR NEW 
APPLICATION TRANSMTTTAL WHERE BENEFIT OF PRIOR US APP LIGATION (S) CLAIMED. 
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10. Fee Calculation (37 C.F.R. 1.16) 



A. [X] Regular application 



CLAIMS AS FILED 


Claims Number Filed 


Basic Fee 
Allowance 


Number Extra 


Rate 


Basic Fee 
37C.F.R. 1.16(a) 
$790.00 


Total Claims 

(37 CFR 1.16(c)) 22 


- 20 = 


2 X 


$ 22.00 


$44.00 


Independent Claims 
(37 CFR 1.16(b)) 3 


- 3 = 


0 X 


$ 82.00 


$0.00 


Multiple Dependent 
Claim(s), if any 0 
(37 CFR 1.16(d)) 




+ 


$270.00 


$0.00 



[ ] Amendment cancelling extra claims is enclosed. 

[ ] Amendment deleting multiple-dependencies is enclosed. 

[ ] Fee for extra claims is not being paid at this time. 

NOTE: If the fees for extra claims are not paid on filing they must be paid or the claims cancelled by amendment, prior to the 
expiration of the time period set for response by the Patent and Trademark Office in any notice of fee deficiency, 37 CFR 
LI 6(d), 

Filing Fee Calculation $ 834.00 

B. [ ] Design application 
($330.00— 37 CFR 1.16(f)) 

Filing Fee Calculation $ 

C. [ ] Plant application 
($540.00— 37 CFR 1.16(g)) 

Filing Fee Calculation $ 
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11. Small Entity Statemeiit(s) 

[ ] Statement(s) thatthis is a filing by a small entity under 37 CFR 1 .9 and 1 .27 is (are) attached. 



WARNING: "Status as a small entity must be specifically established in each application or patent in which the status is 
available and desired Status as a small entity in one application or patent does not affect any other application 
or patent, including applications or patents which are directly or indirectly dependent upon the application or 
patent in which the status has been established. The refiling of an application under § L53 as a continuation, 
division, or continuation-in-part (including a continued prosecution application under § J. 53(d)), or the filing 
of a reissue application requires a new determination as to continued entitlement to small entity status for the 
continuing or reissue application. A nonprovisional application claiming benefit under 35 U.S,C 1 1 9(e), 120, 
121, or 365(c) of a prior application, or a reissue application may rely on a statement filed in the prior 
application or in the patent if the nonprovisional application or the reissue application includes a reference to 
the statement in the prior application or in the patent or includes a copy of the statement in the prior application 
or in the patent and status as a small entity is still proper and desired. The payment of the small entity basic 
statutory filing fee will be treated as such a reference for purposes of this section. "37 CFR L28(a)(2). 

(complete the following^ if applicable) 

[ ] Status as a small entity was claimed in prior application 

I , filed on fi"om which benefit is being 

claimed for this application under: 



35U.S.C.§ [] 119(eX 

[ ] 120, 

[ ] 121, 

[ ] 365(c), 



and which status as a small entity is still proper and desired. 

[ ] A copy of the statement in the prior application is included. 

Filing Fee Calculation (50% of A, B or C above) $ 

NOTE: Any excess of the full fee paid will be refiinded if a small entity status is established refund request are filed within 2 months 
ofthe date of timely payment of a full fee. The two-month period is not extendable under § LI36. 37 CFR L 28(a). 



12. Request for International-Type Search (37 C.F.R. 1 .104(d)) 

(complete, if applicable) 

[ ] Please prepare an international-type search report for this application at the time when 
national examination on the merits takes place. 
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13. Fee Payment Being Made at This Time 



[X] Not Enclosed 

[X] No filing fee is to be paid at this time. 

(This and the surcharge required by 37 C,F,R LI 6(e) can be paid subsequently.) 

[ ] Enclosed 

[ ] Filing fee $ 

[ ] Recording assignment 

($40.00; 37 C.F.R. 1.21(h)) 

(See attached "COVER SHEET FOR 

ASSIGNMENT ACCOMPANYING NEW 

APPLICATION.") $ 

[ ] Petition fee for filing by other 
than all the inventors or person 
on behalf of the inventor where 
inventor refused to sign or cannot 
be reached 

($130.00; 37 C.F.R. 1.47 and 1.17(i)) $ 

[ ] For processing an application with a 

specification in a non-English language 

($130.00; 37 C.F.R. 1.52(d) and 1.17(k)) $ 

[ ] Processing and retention fee 

($130.00; 37 C.F.R. 1.53(d) and 1.21(1)) $ 

[ ] Fee for international-type search report 

($40.00; 37 C.F.R. 1.21(e)) $ 

NOTE: 37CFR L21(l) establishes a fee for processing and retaining any application that is abandons the 
application pursuant to 37 CFR L53(fi and this, as well as the changes to 37 CFR J. 53 and 1. 78(a)(1), indicate that in 
order to obtain the benefit of a prior U.S. application, either the basic filing fee must be paid, or the processing and 
retention fee of§ 1.21(1) must be paid, within 1 year from notification under § 53(f). 

Total Fees Enclosed $ 

14, Method of Payment of Fees 

[ ] Check in the amount of $ . 

[ ] Charge Account No. in the amount of $ . 

A duplicate of this transmittal is attached. 

NOTE: Fees should be itemized in such a manner that it is clear for which purpose the fees are paid. 37 CFR 1 .22(b). 
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15. Authorization to Charge Additional Fees 



If no fees are to be paid on filing, the following items should not be completed. 

Accurately count claims, especially multiple dependent claims, to avoid unexpected high charges, if extra claim 
charges are authorized. 

The Commissioner is hereby authorized to charge the following additional fees by this paper 
and during the entire pendency of this application to Account No. . 

[ ] 37 C.F.R. 1.16(a), (f) or (g) (filing fees) 

[ ] 37 C.F.R. 1 .16(b), (c) and (d) (presentation of extra claims) 

NOTE: Because additional fees for excess or multiple dependent claims not paid on filing or on later presentation must only be 
paid or these claims cancelled by amendment prior to the expiration of the time period set for response by the PTO in any 
notice of fee deficiency (37 CFR L 16(d)), it might be best not to authorize the PTO to charge additional claim fees, except 
possibly when dealing with amendments after final action. 

[ ] 37 C.F.R. 1.16(e) (surcharge for filing the basic filing fee and/or declaration on a 
date later than the filing date of the application) 

[ ] 37 CFR 1.17(a)(l)-(5) (extension fees pursuantto § 1.136(a). 

[ ] 37 C.F.R. 1.17 (application processing fees) 

NOTE: "A written request may be submitted in an application that is an authorization to treat any concurrent or future reply, 
requiring a petition for an extension of time under this paragraph for its timely submission, as incorporating a petition for 
extension of time for the appropriate length of time. An authorization to charge all required fees, fees under § LI 7, or all 
required extension of time fees will be treated as a constructive petition for an extension of time in any concurrent or future 
reply requiring a petition for an extension of time under this paragraph for its timely submission. Submission of the fee set 
forth in § LI 7(a) will also be treated as a constructive petition for an extension of time in any concurrent reply requiring 
a petition for an extension of time under this paragraph for its timely submission, "37 CFR LI 36(a)(3). 

[ ] 37 C.F.R. 1.1 8 (issue fee at or before mailing of Notice of Allowance, pursuant to 3 7 
C.F.R. 1.311(b)) 

NOTE: Where an authorization to charge the issue fee to a deposit account has been filed before the mailing of a Notice of 
Allowance, the issue fee will be automatically charged to the deposit account at the time of mailing the notice of allowance. 
37 CFR 13 1 1(b)). 

NOTE: 37 CFR L28(b) requires ''Notification of any change in status resulting in loss of entitlement to small entity status must 
be filed in the application . . . prior to paying, or at the time of paying, . . issue fee. " From the wording of 37 CFR L28(b). 
(a) notification of change of status must be made even if the fee is paid as "other than a small entity** and (b) no 
notification is required if the change is to another small entity. 



WARNING: 
WARNING: 

[ ] 
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16. Instructions as to Overpayment 

NOTE: . . Amounts of twenty-five dollars or less will not be returned unless specifically requested within a reasonable time, nor 
will the payer be notified of such amounts; amounts over twenty-five dollars may be returned by check or, if requested, by 
credit to a deposit account "37 CFR L 26(a). 

[ ] Credit Account No. . 



[ ] 



Refund 




Reg. No. 3 1,029 



Ralph E. Jocke 



(type or print name of practitioner) 



Tel. No.: (330) 722-5143 



231 South Broadway 



P.O. Address 



Customer No.: 



Medina. Ohio 44256 
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[X] Incorporation by reference of added pages 

(check the following item if the application in this transmittal claims the benefit of prior U.S. 
application(s) (including an international application entering the U.S. stage as a continuation, 
divisional or C-I-P application) and complete and attach the ADDED PAGES FOR NEW 
APPLICATION TRANSMITTAL WHERE BENEFIT OF PRIOR US APPLICATION(S) CLAIMED) 

[X] Plus Added Pages for New Application Transmittal Where Benefit of Prior U.S. 
Application(s) Claimed 

Number of pages added 5 

[ ] Plus Added Pages for Papers Referred to in Item 4 Above 

Number of pages added 



[X ] Plus added pages deleting names of inventor(s) named on prior application(s) who is/are no 
longer inventor(s) of the subject matter claimed in this application. 

Number of pages added 1 

[ ] Plus "Assignment Cover Letter Accompanying New Application" 

Number of pages added 



[ ] Statement Where No Further Pages Added 

(if no further pages form a part of this Transmittal, then end this Transmittal with this page and check 
the following item) 

[ ] This transmittal ends with this page. 
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Practitioner's Docket No. 



D1077+8 



PATENT 



ADDED PAGES FOR APPLICATION TRANSMITTAL WHERE BENEFIT OF 
PRIOR U.S. APPLICATION(S) CLAIMED 

NOTE: See37CFR}J8. 
17. Relate Back 

WARNING: If an application claims the benefit of the filing date of an earlier filed application under 35 U,S.C 120, 121 or 
365(c), the 20-year term of that application will be based upon the filing date of the earliest U.S. application that the 
application makes reference to under 35 U.S.C 120, 121 or 365(c). (35 U.S.C 154(a)(2) does not take into account, 
for the determination of the patent term, any application on which priority is claimed under 35 U.S.C. 119, 365(a) 
or 365(b).) For a c-i-p application, applicant should review whether any claim in the patent that will issue is 
supported by an earlier application and, if not, the applicant should consider canceling the reference to the earlier 
filed application. The term of a patent is not based on a claim-by-claim approach. See Notice of April 1 4, 1 995, 60 
Fed Reg 20,195, at 20,205. 

(complete the following, if applicable) 
[X] Amend the specification by inserting, before the first line, the following sentence: 
A. 35 U.S.C. 119(e) 

NOTE: ''Any nonprovisional application claiming the benefit of one or more prior filed copending provisional applications must 
contain or be amended to contain in the first sentence of the specification following the title a reference to each such prior 
provisional application, identifying it as a provisional application, and including the provisional application number 
(consisting of series code and serial number). " 37 C.F.R. § 1.78(a)(4). 

[X] "This application claims the benefit of U.S. Provisional Application(s) No(s).: 
APPLICATION NO(S).: FILING DATE 
60 /QQ1.887 07/07/1998 



60 /0Q5.626 0^/07/1998 



60 /0Q8.907 09/02/1998 



B. 35 U.S.C. 120, 121 and 365(c) 

NOTE: ''Except for a continued prosecution application filed under § 1.53(d), any nonprovisional application claiming the benefit 
of one or more prior filed copending nonprovisional applications or international applications designating the United 
States of America must contain or be amended to contain in the first sentence of the specification following the title a 
reference to each such prior application, identifying it by application number (consisting of the series code and serial 
number) or international application number and international filing date and indicating the relationship of the 

applications Cross-references to other related applications may be made when appropriate. " (See § 1.1 4(a)). 37 

C.F.R. § 1.78(a)(2). 

[X] "This application is a 

[ ] continuation 
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[X] continuation-in-part 



[ ] divisional 
of copending appiication(s) 

[X] application number 09 / 077.337 filed on 05/27/1998 " 

[X] International Application PCT/US97/21422 filed on 11/25/1997 

and which designated the U.S." 

NOTE: The proper reference to a prior filed PCT application that entered the US, national phase is the U.S. serial number and 
the filing date of the PCT application that designated the U.S. 

NOTE: (I) Where the application being transmitted adds subject matter to the International Application, then the filing can be 
as a continuation-in-part or (2) if it is desired to do so for other reasons then the filing can be as a continuation. 

NOTE: The deadline for entering the national phase in the U.S. for an international application was clarified in the Notice of April 
28, 1987 (1079 O.G. 32 to 46) as follows: 

"The Patent and Trademark Office considers the International application to be pending until the 22nd month from the 
priority date if the United States has been designated and no Demand for International Preliminary Examination has been 
filed prior to the expiration of the 19th month from the priority date and until the 32nd month from the priority date if a 
Demand for International Preliminary Examination which elected the United States of America has been filed prior to the 
expiration of the 1 9th month from the priority date, provided that a copy of the international application has been 
communicated to the Patent and Trademark Office within the 20 or 30 month period respectively If a copy of the 
international application has not been communicated to the Patent and Trademark Office within the 20 or 30 month period 
respectively the international application becomes abandoned as to the United States 20 or 30 months from the priority 
date respectively. These periods have been placed in the rules as paragraph (h) of§ 1.494 and paragraph (i) of§ 1.495. 
A continuing application under 35 US.C 365(c) and 120 may be filed anytime during the pendency of the international 
application. " 

[X] "The nonprovisional application designated above, namely application 

09 / 077.337 „ , filed 05/27/1998 , claims the benefit of 

U.S. Provisional Application(s) No(s).: 



APPLICATION NO(S).: FILING DATE 

60 / 03L956 11/27/1996 

/ „ 

/ — 

[ ] Where more than one reference is made above please combine all references into one sentence. 
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18. Relate Back— 35 U.S.C. 119 Priority Claim for Prior Application 

The prior U.S. application(s), including any prior International Application designating the U.S., identified 
above in item 17B, in turn itself claim(s) foreign priority(ies) as follows: 



Country Appln. no. Filed 

The certified copy(ies) has (have) 

[ ] been filed on , in prior application 0 / , which was filed on 



[ ] is (are) attached. 

WARNING: The certified copy of the priority application that may have been communicated to the PTO by the International 
Bureau may not be relied on without any need to file a certified copy of the priority application in the continuing 
application. This is so because the certified copy of the priority application communicated by the International 
Bureau is placed in a folder and is not assigned a U.S. serial number unless the national stage is entered. Such 
folders are disposed of if the national stage is not entered. Therefore, such certified copies may not be available if 
needed later in the prosecution of a continuing application. An alternative would be to physically remove the priority 
documents from the folders and transfer them to the continuing application. The resources required to request 
transfer, retrieve the folders, make suitable record notations, transfer the certified copies, enter and make a record 
of such copies in the Continuing Application are substantial Accordingly, the priority documents in folders of 
international applications that have not entered the national stage may not be relied on. Notice of April 28, 1987 
(1079 O.G. 32 to 46). 

19. Maintenance of Copendency of Prior Application 

NOTE: The PTO finds it useful if a copy of the petition filed in the prior application extending the term for response is filed with 
the papers constituting the filing of the continuation application. Notice of November 5, 1 985 (1060 O.G, 27). 

A. [ ] Extension of time in prior application 

(This item must be completed and the papers filed in the prior application, if the period set in the prior 

application has run.) 

[ ] A petition, fee and response extends the term in the pending prior application until . 

[ ] A copy of the petition filed in prior application is attached. 

B. [ ] Conditional Petition for Extension ofTime in Prior Application 

(complete this item, if previous item not applicable) 
[ ] A conditional petition for extension of time is being filed in the pending prior application. 
[ ] A copy of the conditional petition filed in the prior application is attached. 
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20. Further Inventorship Statement Where Benefit of Prior Application(s) Claimed 

(complete applicable item (a), (b) and/or (c) below) 

(a) [ ] This application discloses and claims only subject matter disclosed in the prior application whose 
particulars are set out above and the inventor(s) in this application are 

[ ] the same. 

[ ] less than those named in the prior application. It is requested that the following inventor(s) 
identified for the prior application be deleted: 



(type name(s) of inventor(s) to be deleted) 

(b) [X] This application discloses and clauns additional disclosure and a new declaration or oath is being filed. 

With respect to the prior application, the inventor(s) in this application are 

[ ] the same, 

[X] the following additional inventor(s) have been added: 

Joseph C. Ess. David W Weis. Bruce G. Richards. James Church 

(type name(s) of inventor(s) to be added) 

(c) [X] The inventorship for all the claims in this application are 

[X] the same. 

[ ] not the same. An explanation, including the ownership of the various claims at the time the last 
claimed invention was made 

[ ] is submitted. 

[ ] will be submitted. 

21. Abandonment of Prior Application (if applicable) 

[ ] Please abandon the prior application at a time while the prior application is pending, or when the 
petition for extension of time or to revive in that application is granted, and when this application is 
granted a filing date, so as to make this application copending with said prior application. 

NOTE: According to the Notice of May 13, 1983 (103, TMOG 6-7), the filing of a continuation or continuation-in-part application 
is a proper response with respect to a petition for extension of time or a petition to revive and should include the express 
abandonment of the prior application conditioned upon the granting of the petition and the granting of a filing date to the 
continuing application. 
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22. Petition for Suspension of Prosecution for the Time Necessary to File an Amendment 

WARNING: "The claims of a new application may be finally rejected in the first Office action in those situations where (J) the 
new application is a continuing application of, or a substitute for, an earlier application, and (2) all the claims of 
the new application (a) are drawn to the same invention claimed in the earlier application, and (b) would have been 
properly finally rejected on the grounds of art of record in the next Office action if they had been entered in the earlier 
application, " MPEP, § 70d07(b). 

NOTE: Where it is possible that the claims on file will give rise to a first action final for this continuation application and for some 
reason an amendment cannot be filed promptly (e.g., experimental data is being gathered) it may be desirable to file a 
petition for suspension of prosecution for the time necessary. 

(check the next item, if applicable) 

[ ] There is provided herewith a Petition To Suspend Prosecution for the Time Necessary to File An 
Amendment (New Application Filed Concurrently) 

23. Small Entity (37 CFR § 1. 28(a)) 

[ ] Applicant has established small entity status by the filing of a statement in parent application 
/ on . 

[ ] A copy of the statement previously filed is included. 

WARNING: See 37 CFR § L 28(a). 

24. NOTIFICATION IN PARENT APPLICATION OF THIS FILING 

[ ] A notification of the filing of this 
(check one of the following) 

[ ] continuation 

[ ] continuation-in-part 

[ ] divisional 

is being filed in the parent application, from which this application claims priority under 35 U.S.C. § 120. 
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ADDED PAGE(S) FOR APPLICATION TRANSMITTAL WHERE BENEFIT 
OF A PRIOR U.S. APPLICATION CLAIMED 

The following inventors who were named on prior applications, are no longer inventors of the subject 
matter claimed in this application: 

Lilei Chen. Bradrick O. Lepper. Robert J. Lemlev. Michael E. Califf. Jr.. Shawn D. Jovce, 
Phillip S. Moore. Steven C. Swinsler 
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TITLE: AUTOMATED BANKING 
MACHINE AND SYSTEM 
INVENTORS: DRUMMOND, ET AL. 
DOCKET: D1077+8 



TECHNICAL FIELD 



This invention relates to automated banking machines. Specifically this invention relates 
to an automated banking machine apparatus and system that is capable of use in a wide area 
network, which provides a user with a familiar interface from their home institution at banking 
machines operated by other institutions, and which provides greater options for machine outputs. 



BACKGROUND ART 



Automated banking machines are well known. A common type of automated banking 
machine used by consumers is an automated teller machine ("ATM"). ATMs enable customers 
to carry out banking transactions. Common banking transactions that may be carried out with 
ATMs include the dispensing of cash, the making of deposits, the transfer of funds between 
accomts, the payment of bills and account balance inquiries. The type of banking transactions a 
customer can carry out are determined by capabilities of the particular banking machine and the 
programming of the institution operating the machine. Other types of automated banking 
machines may allow customers to charge against accoimts or to transfer funds. Other types of 
automated banking machines may print or dispense items of value such as coupons, tickets, 
wagering slips, vouchers, checks, food stamps, money orders, scrip or travelers checks. For 
purposes of this disclosure an automated banking machine or automated transaction machine 
shall encompass any device which carries out transactions including transfers of value. 
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Currently ATMs are operated in proprietary communications networks. These networks 
interconnect ATMs operated by financial institutions and other entities. The interconnection of 
the networks often enables a user to use a banking machine operated by another institution if the 
foreign institution's banking machine is interconnected with the network that includes the user's 
5 institution. However when the customer operates the foreign institution's machine the customer 
must operate the machine using the customer interface that has been established by the foreign 
institution for its banking machines. In addition the user is limited to the transaction options 
provided by the foreign institution. 

A customer may encomter difficulties when using a foreign institution's machine. 
1 0 a Problems may occur because the user is not familiar with the type of machine operated by the 
H foreign institution. Confusion may result because the customer does not know which buttons or 
y other mechanisms to actuate to accomplish the desired transactions. The transaction flow for a 
m customer at a foreign institution machine may be significantly different from machines operated 
U by the user's home institution. This may be particularly a problem when the user is from another 
1 5 coimtry and is not familiar with the type of banking machine or the language of the interface 
S provided by the foreign institution. Likewise, the docimients which are printed by printers in an 
automated banking machine are generally limited to a limited group of defined formats in a 
single language. 

A foreign institution may also provide different types of transactions than the user is 
20 familiar with at their home institution. For example the user's home institution may enable the 

transfer of funds between accounts through their automated banking machines, to enable the user 
to maintain funds in higher interest bearing accounts until they are needed. If the foreign 
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institution does not provide this capability, the user will be unable to do this when operating the 
foreign machine. The inability of a user at a foreign machine to conduct the transactions that 
they are accustomed to may present problems. 

The networks that operate automated teller machines and other types of automated 
5 banking machines generally operate proprietary networks to which access is restricted. This is 
necessary to prevent fraud or tampering with the network or user's accounts. Proprietary 
networks are also generally used for the transmission of credit card messages and other financial 
transaction messages. Access to such credit card processing systems is also restricted primarily 
for purposes of maintaining security. 
1 0 fj Communication over wide area networks enables messages to be communicated between 

H distant locations. The best known wide area network is the Internet which can be used to provide 
W communication between computers throughout the world. The Internet is not widely used for 
S financial transaction messages because it is not a secure system. Messages intended for receipt at 
L a particular computer address may be intercepted at other addresses without detection. Because 
1 5 the messages may be intercepted at locations that are distant in the world from the intended 
recipient, there is potential for fraud and corruption. 

Companies are beginning to provide approaches for more secure transmission of 
messages on the Internet. Encryption techniques are also being applied to Internet messages. 
However the openness of the Internet has limited its usefiilness for purposes of financial 
20 messages, particularly financial messages associated with the operation of automated banking 
machines. 
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Messages in wide area networks may be communicated using the Transmission Control 
Protocol/Internet protocol ("TCP/IP"). U.S. Patent No. 5 J06,422 shows an example of a system 
in which financial information stored in databases is accessed through a private wide area 
network using TCP/IP messages. The messages transmitted in such networks which use TCP/IP 
5 may include "documents" (also called "pages"). Such documents are produced in Hypertext 
Markup Language ("HTML") which is a reference to a type of programming language used to 
produce documents with commands or 'tags" therein. The tags are codes which define features 
and/or operations of the document such as fonts, layout, imbedded graphics and hypertext links. 
HTML docximents are processed or read through use of a computer program referred to as a 
10 "browser". The tags tell the browser how to process and control what is seen on a screen and/or 
|2 is heard on speakers connected to the computer running the browser when the document is 
U processed. HTML documents may be transmitted over a network through the Hypertext Transfer 
£ Protocol ("HTTP"). The term "Hypertext" is a reference to the ability to embed links into the 
text of a document that allow communication to other documents which can be accessed in the 
15y, network. 

if j Thus there exists a need for an automated banking machine and system that can be used 

in a wide area network such as the Internet while providing a high level of security. There 
further exists a need for an automated banking machine and system which provides a user with 
the familiar interface and transaction options of their home institution when operating foreign 
20 institution machines. There further exists a need for a machine which may provide more 
transaction options and types of promotional and printed materials to users. 
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DISCLOSURE OF INVENTION 



It is an object of the present invention to provide an automated banking machine at which 
a user may conduct transactions. 

It is a further object of the present invention to provide an automated banking machine 
that may be operated through connection to a vdde area network. 

It is a further object of the present invention to provide an automated banking machine 
and system that provides a user with a familiar interface and transaction options of their home 
institution at machines operated by foreign institutions. 

It is a further object of the present invention to provide an automated banking machine 
that communicates using HTML documents and TCP/IP messages. 

It is a further object of the present invention to provide an automated banking machine 
that enables the connection of the banking machine to a user's home institution through HTML 
documents and TCP/IP messages generated responsive to indicia on a card input by a user. 

It is a further object of the present invention to provide an automated banking machine 
and system that accomplishes transactions over a wide area network while maintaining a high 
level of security. 

It is a further object of the present invention to provide an automated banking machine 
and system that controls connection of the banking machine to foreign addresses through a proxy 
server. 

It is a further object of the present invention to provide an automated banking machine 
that limits the operation of devices in the machine through a local device server. 
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It is a further object of the present invention to provide an automated banking machine 
and system that is operable through connection to the Internet. 

It is a further object of the present invention to provide an automated banking machine 
that may be used to provide a user with more types of messages including messages targeted to 
5 particular users. 

It is a further object of the present invention to provide an automated banking machine 
which is capable of providing users with a wider variety of printed documents. 

It is a further object of the present invention to provide an automated banking machine 
which provides additional options for identifying authorized users, 
10 O It is a further object of the present invention to provide an automated banking machine 

fin that can be used in connection with existing transaction systems while providing enhanced 
m functionality. 

m It is a further object of the present invention to provide an automated banking machine 

f ' which provides enhanced diagnostic and service capabilities. 
1 5 ^ It is a further object of the present invention to provide an automated banking machine 

m which performs transactions at a rapid pace. 

It is a further object of the present invention to provide improved systems in which 
automated banking machines are used. 

It is a further object of the present invention to provide improved methods of operation 
20 for automated banking machines and systems. 

Further objects of the present invention will be made apparent in the following Best 
Modes for Carrying Out Invention and the appended Claims. 
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The foregoing objects are accomplished in a preferred embodiment of the invention by an 
automated banking machine that includes an output device such as a display screen, and an input 
device such as a touch screen or a keyboard. The banking machine further includes devices such 
as a dispenser mechanism for sheets of currency, a printer mechanism, a card reader/writer, a 
5 depository mechanism and other physical transaction function devices that are used by the 
machine to accomplish banking transactions. 

The banking machine further includes a computer. The computer is in operative 
connection with the output devices and the input devices, as well as v^th the sheet dispenser 
mechanism, card reader and other physical transaction function devices in the banking machine. 
1 0 ^ The computer includes software programs that are executable therein. The software programs 
^ include an HTML document handling portion. The HTML document handling portion operates 
m to send and receive HTML documents and HTTP messages. The HTML document handling 
CP portion is preferably in connection v^th the output device to display screens including hypertext 
f ;^ link indicators. The HTML document handling portion is also preferably in connection with the 
15 n input device which enables user selection and the generation of response messages from the 
ffl computer. The HTML document handling portion preferably operates in connection with a 
JAVA software environment and has the capability of executing instructions in JAVA script 
transmitted v^th HTML documents. 

The software in the computer further preferably includes a device application portion. 
20 The device application portion includes software that is operative to control the sheet dispenser 
and other devices. In the preferred form of the invention the device application portion includes 
a plurality of JAVA applets for operating the devices in the machine. 
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The computer in the automated banking machine further includes a device interfacing 
software portion. The device interfacing software portion operates to receive messages from the 
device application portion and to cause the devices to operate through appropriate hardware 
interfaces. In one preferred form of the automated banking machine, the HTML document 
5 handling portion, device application portion and device interfacing software portion each reside 
on the same computer and communicate at different IP ports. 

The automated banking machine of the invention in one configuration communicates 
using TCP/IP messages in an intranet which includes a plurality of such machines. The intranet 
is in tum connected to at least one computer which is operated by a home institution. The home 
1 0 y institution is the entity that operates the banking machines. 

^ The computer of the home institution preferably includes a home HTTP server, a proxy 

ffi server and a device server. The proxy server commimicates through the intranet with the HTML 
01 document handling portion of the software in each of the banking machines. The proxy server is 
r also connectable to a wide area network, such as the Internet, to which ft)reign servers are 
1 5 n cormected. The device server is operative to pass messages between the device application 
m portion and the device interfacing software portion of the banking machines. The device server 
may include monitor software which monitors and selectively limits the use and operation of the 
devices in the banking machine. This provides a level of security. 

The automated banking machine and system is operative to place a user in cormection 
20 with the institution where they have their accounts. This can be either the home institution that 
operates the banking machine where the user is present, or a foreign institution which is 
connected to the wide area network. To operate the banking machine a user provides inputs 
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which correspond to an address, such as a URL address, through an address input device. The 
HTML document handling portion operates to connect the banking machine to the server 
corresponding to that address. This is preferably accomplished by the user having indicia 
representative of the address on a card that is read by a card reader in the banking machine, or 
other input device which identifies the user or an institution or entity with which the user has 
accounts. 

The HTML document handling portion is responsive to the address on the card or other 
input data to connect through the proxy server to the user's institution. If the user's home 
institution address corresponds to the home server, the banking machine operates responsive to 
messages from the home server. If however the user^s input address corresponds to an address of 
a foreign server, the proxy server is operative to communicate through the wide area network 
with the foreign server at the customer's home institution. If the customer causes the machine to 
connect a server operated by a foreign institution, the HTML documents sent from the foreign 
institution correspond to those normally provided by the foreign institution. As a result the 
customer is familiar with the interface produced by these documents and will be able to more 
readily operate the banking machine. 

The foreign server or home server operate the banking machine by sending HTML 
documents that include instructions for operating the devices in the banking machine. The 
instructions are transmitted from the HTML document handling portion to the device application 
portion of the software, which operates the devices in response to the instructions. The 
instructions from the device application portion to the devices in the automated banking machine 
are passed through the device server of the home institution. This helps to maintain security. In 



addition, the proxy server includes screening software which limits the foreign servers which 
may cormect to and operate the banking machine. This is referred to as a "fire wall" 

Embodiments of the present invention also provide enhanced user interfaces and for the 
printing of a wide variety of docxaments with the banking machine. The invention also enables 
achieving enhanced functionality while utilizing existing transaction networks and automated 
transaction machines. 

BRIEF DESCRIPTION OF DRAWINGS 

Figure 1 is a schematic view of a network configuration including the automated banking 
machine apparatus and system of the present invention. 

Figure 2 is a schematic view of a preferred embodiment of an automated banking 
machine of the present invention. 

Figures 3 through 24 show schematic views of the automated banking machine, an 
intranet connecting the banking machine to a computer system of a home bank and a wide area 
network connecting the computer system of the home bank to a foreign bank. 

Figures 3 through 18 schematically represent steps in a transaction carried out at the 
banking machine with the computer system of the home bank. 

Figures 19 through 24 schematically represent steps in a transaction carried out at the 
banking machine v^th the computer system of the foreign bank. 

Figure 25 is a schematic view of a network configuration including an alternative 
embodiment of the automated banking machine of the present invention. 
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Figure 26 is a schematic view of frames in the HTML document handling portion of the 
alternative embodiment of the automated banking machine shown in Figure 25. 

Figure 27 is a schematic view of a customer interface of an automated banking machine 
and the function keys and keypad keys included in the interface. 

Figures 28-30 schematically represent exemplary steps in converting function key and 
keypad key inputs to keyboard stream and mouse stream inputs. 

Figure 31 schematically represents exemplary steps in printing documents with the 
automated banking machine. 



BEST MODES FOR CARRYING OUT INVENTION 



Referring now to the drawings and particularly to Figure 1 , there is shown therein a 
network configuration schematically indicated 10, which includes the automated banking 
machine apparatus and system of one preferred embodiment of the present invention. Network 
10 includes a plurality of automated banking machmes 12 which in the preferred embodiment of 
the invention are ATMs. ATMs 12 are connected to a computer system of a home bank 
schematically indicated 14. Home bank computer system 14 is the computer system that is 
operated by the bank or other institution which has primary responsibility for the ATMs 12. 
Home bank computer system 14 is connected to the ATMs 12 through an intranet 16. Intranet 16 
is preferably a local or proprietary network that provides communication between the computer 
system 14 and the banking machines 12 using messages in the transmission control 
protocol/internet protocol ("TCP/IP") format. 
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The messages that are communicated through the intranet 16 are preferably TCP/IP 
messages and hypertext mark up language ("HTML") documents. In one preferred embodiment 
of the invention the HTML documents sent through intranet 16 include embedded object oriented 
programming instructions, preferably in the JAVA® format which has been developed by Sun 
5 Microsystems. The messages sent through intranet 16 may be sent in an encrypted or 

unencrypted form depending on the nature of the system and the security needs of the home 
bank. 

It should be understood that embodiments of the invention may process other forms of 
documents which include tags or instructions therein. For example a form of "extended" HTML 
1 0 O has recently been proposed which may be used in embodiments of the invention. For purposes of 
^ the invention all such forms of languages and variants which include documents, which 
m documents include instructions therein shall be referred to as HTML documents. Likewise, 
dl while JAVA® is used in the described embodiment, other programming languages may be used. 
H= For example, Active-X™ developed by Microsoft Corporation or other languages may be used in 
15 other embodiments. Further it should be understood that the instructions included in documents 
S may be operative to cause a computer to access other documents, records or files at other 
addresses to obtain a program to carry out an operation. 

Home bank computer system 14 is also connectable as shown to a wide area network 1 8. 
In some embodiments of the invention the v^de area network 18 is the Internet. In other 
20 embodiments of the invention, other wide area networks may be used. The wide area network 

preferably communicates messages in TCP/IP between numerous computer systems connected to 
the wide area network. These foreign computer systems are schematically represented by servers 
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20, 22, 24, 26 and 28. It should be understood that servers 20 through 28 may be operated by or 
connected to other financial institutions throughout the world. Servers 20 through 28 preferably 
operate by conimxinicating HTML documents and other HTTP messages. 

Figure 2 shows a schematic view of the ATM 12 used in connection with one preferred 
embodiment of the invention. ATM 12 includes a touch screen 30. Touch screen 30 includes a 
display screen which serves as an output device for communication with a user of the machine. 
Touch screen 30, because it is a touch screen, also serves as an input device for receiving input 
instructions from a user. Touch screen 30 is connected through an interface 32 to a computer 34 
which is preferably housed within the machine. Alternative embodiments of the invention may 
include other output devices such as audio speakers. 

Computer 34 is also in connection with a plxirality of transaction function devices 36 
which are included in ATM 12. Devices 36 include for example, a card reader/v^iter mechanism 
38 and a keyboard 40. Devices 36 further include a sheet dispenser mechanism 42 which is 
operative to dispense sheets, which in some preferred forms of the invention are currency or bank 
notes. Devices 36 also include a depository 44 for accepting deposits into a secure location in 
the machine. A receipt printer 46 for providing transaction receipts to customers is also included 
among devices 36. A journal printer 48 is also included among the devices for keeping a hard 
copy record of transaction information. In other embodiments other or additional transaction 
function devices which carry out other transaction functions may be used. Other embodiments 
may include fewer transaction function devices. It should be further understood that while the 
described embodiment of the invention is an automated banking machine, the principles of the 
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invention may be employed in many types of transaction machines that do not necessarily carry 
out banking transactions. 

Each of the devices is operatively connected to an intemal control bus 50 v^ithin the 
banking machine 12. The control bus 50 outputs the intemal messages to the particular devices. 
Each device has an appropriate hardware interface which enables the particular device to operate 
to carry out its respective function in response to the messages transmitted to it on control bus 50. 
Card reader/writer 38 has a hardware interface schematically shown as 52. Hardware interfaces 
54, 56, 58, 60 and 62 are respectively operative to connect keyboard 40, sheet dispenser 
mechanism 42, depository mechanism 44, receipt printer mechanism 46 and journal printer 
mechanism 48 to the control bus 50. 

Computer 34 has several software programs that are executable therein. In the preferred 
embodiment of the invention these software programs include a device interfacing software 
portion generally indicated 64. Device interfacing software portion 64 preferably includes a 
software device interface 66 that communicates electronic messages with the control bus 50. The 
device interface software portion 64 also preferably includes a device manager 68. The device 
manager is preferably operative to manage the various devices 36 and to control their various 
states so as to be assured that they properly operate in sequence. The device manager is also 
preferably operable to create device objects in the software so as to enable operation of the 
devices by at least one object oriented program 70. Device interfacing software portion 64 also 
includes the object oriented program portion 70, which in one preferred embodiment is an 
application written in the JAVA language. Program 70 works in conjunction with the device 
manager to receive object oriented JAVA messages which cause the devices to operate, and to 
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transmit device operation messages indicative of a manner in v^hich devices are operating and/or 
are receiving input data. 

The device interfacing software portion 64 in the described embodiment operates on 
computer 34 and communicates through a physical TCP/IP connection 72 with the intranet 16. 
The physical connection may be analog dial-up, serial port, ISDN connection or other suitable 
connection. In the configuration of the system as shown, device interfacing software portion 64 
communicates at the IP address of computer 34 and at an IP port or socket indicated 74 that is 
different from the other software applications. In other embodiments of the invention, device 
interfacing software portion 64 may operate in a different computer than the other software 
applications of the invention. 

It should finther be understood that although in the preferred embodiment of the 
invention the device interfacing portion 64 is software, in other embodiments of the invention all 
or portions of the instruction steps executed by software portion 64 may be resident in firmware 
or in other program media in cormection with one or more computers, which are operative to 
coramunicate v^th devices 36. For purposes of the invention all such forms of executable 
instructions shall be referred to as software. 

Other software also operates in computer 34. This software includes HTML document 
handling software which includes a browser, schematically indicated 76. In the preferred 
embodiment of the invention the HTML document handling software includes a browser 
provided by Netscape®. However in other embodiments other HTML document handling and 
communicating software and browser software, such as Hot JAVA® by Sun Microsystems or 
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Internet Explorer™ jft-om Microsoft, may be used. Browser 76 communicates in computer 34 at 
an IP port indicated by 78, 

Browser 76 is in operative connection with JAVA environment software 80 which 
enables computer 34 to run JAVA language programs. JAVA language programs have the 
advantage that they operate the same on a variety of hardware platforms without modification. 
This "write once\run anywhere" capability makes the JAVA environment well-suited for the 
described embodiment of the invention. However other embodiments may use different types of 
software programs. 

The JAVA environment software 80 enables computer 34 to execute instructions in 
JAVA script, schematically indicated 82. The instructions that are executed by the computer in 
JAVA script are preferably embedded JAVA script commands that are included in the HTML 
documents which are received through the browser 76. The browser 76 in connection with the 
JAVA envirormient software 80 which executes instructions in the embedded JAVA script 82, 
serve as an HTML document handling software portion for transmitting and receiving HTML 
documents and TCP/IP messages through the IP port indicated by 78. 

Computer 34 also has executable software therein having a device application portion 84. 
The device application portion 84 contains executable instructions related to operation of the 
devices 36. In the preferred embodiment of the invention, the device application portion consists 
of a plurality of JAVA applets. In the described embodiment the applets are also preferably 
programs operable to control and keep track of the status of the devices with which they are 
associated. Certain applets are also preferably operable to configure the browser to communicate 
messages. Certain applets manage security and authenticate entities that use the ATM. 
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In the described form of the invention, JAVA applets are associated with functions such 
as enabling the card reader mechanism, notifying the browser when a user's card data has been 
entered, operating the receipt printer mechanism, operating the journal printer mechanism, 
enabling the customer keyboard and receiving data input through the keyboard, operating the 

5 sheet dispenser mechanism, operating the depository, navigating to document addresses, timing 
device functions, verifying digital signatures, handling encryption of messages, controlling the 
mix of bills dispensed from multiple sheet dispenser mechanisms, calculating foreign exchange, 
and ending a transaction and instructing the browser to return to commimication with the home 
server. Of course, in other embodiments, other applets may be used to control devices and use 

1 0 O data to carry out various desired functions with the machine. The device application portion 84 
^ communicates in the computer 34 at an IP port indicated 86. 

S In the described embodiment of the invention, the device application portion 84 of the 

fli software does not communicate its messages directly to the device interfacing software portion 
H 64. As later explained, this provides heightened security. However it should be understood that 
1 5 h embodiments of the invention may provide for the device application portion 84 to directly 
1^ communicate device operation messages to the device program 70. This may be done either 
internally using TCP/IP, by delivery of messages in a conventional manner through a queue 
established in the operating system of the computer that is associated with the software that 
interfaces v^th the devices, or by direct call to this software. 
20 From the foregoing discussion it will also be appreciated that certain applets in the device 

application portion 84 may correspond to devices which are not present in all automated teller 
machines. For example an automated teller machine that operates only as a cash dispenser does 
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not include a depository mechanism like depository 44. To accommodate the situation where a 
user requests a transaction that is not physically possible with the ATM 12, the device interfacing 
software portion 64 may be programmed to provide an appropriate response message to indicate 
that the function is not available. 
5 Alternatively, the device interfacing software portion may include a function which 

checks for the presence or absence of each type of physical device within the ATM. Information 
indicative of the devices present m the ATM may be included as part of the messages generated 
by the ATM. For example, information indicative of the devices which are operative in the ATM 
may be included as a portion or several parts of the URL addresses to which messages are 
1 0 O directed by the ATM. In this way, the URL in the server to which the ATM connects may be 
^ configured for providing only HTML documents which correspond to the types of transactions 
m that the ATM is capable of performing. As a result the browser avoids displaying documents 
Qi which include references to transaction types that the machine is not capable of performing. 
^ Thus for example, a machine may avoid producing a display in response to a document which 
1 5 n includes a reference to a deposit transaction if the machine does not include a depository. 
S Altematively the machine may include in memory, data representative of the fimctional 

devices included in the machine. This may include for example data representative of a plurality 
of devices in the machine and the configurations of such devices, or altematively, a designator 
such as a machine number sufficient to identify the capabilities of the machine. The device data 
20 indicative of the functional devices in the machine is communicated to a server and the server is 
operative to deliver the appropriate HTML documents for the devices present in the machine. 
This may be done based on the data corresponding to the device data fi-om the machine or may be 
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resolved from a memory which holds data representative of the functional devices in a machine 
associated v^th a particular designator. Documents selectively delivered by the server to the 
browser of the machine will include the appropriate references to the functional devices present 
in the machine. These documents may be static documents or may be generated at run time from 
sub-documents or otherwise, to provide the appropriate outputs and instructions to the output 
devices of the transaction machine. 

Figxire 3 shows the ATM 12 in communication through the intranet 16 with the home 
bank computer system 14, Computer system 14 includes a proxy server 88. System 14 further 
includes a home HTTP server 90. Computer system 14 further includes a device server 92. The 
proxy server, home HTTP server and device server may be included in a single computer as 
shown, or in other embodiments may be separate computers. Additional servers may be 
operative in other embodiments. 

The home HTTP server 90 is preferably in communication with a data store and is in 
electronic communication with a back office computer system, schematically indicated 94. Back 
office computer system 94 is operative to keep track of debiting or crediting customers' accounts 
when they conduct transactions at the automated banking machines. In addition back office 94 is 
also preferably operative to track transactions for purposes of accomplishing settlements with 
other institutions who are participants in the system and whose customers conduct transactions at 
the ATMs 12. 

As later explained, proxy server 88 is also operative in the described embodiment to 
communicate through the wide area network 18 with foreign servers such as foreign server 96. 
Foreign server 96 is an example of a server operated by an institution or entity other than the 
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institution which operates computer system 14. It should be understood that while foreign server 
96 is indicated as operated by a "foreign" institution, this is not necessarily indicative that the 
institution is located in another country from the institution that operates computer system 14. 
However, it is possible that foreign server 96 could be located in such a foreign country, 
including a country in which the language spoken is different from that generally used in the 
country where ATM 12 is located. 

The conduct of transactions using the ATM 12 is now explained with reference to Figures 
3-24. It should be understood that the following described transaction flows are merely examples 
of the operation of the apparatus and system, and the apparatus and system may be configured 
and operated in numerous ways to carry out transactions. 

At the start of an exemplary transaction, as schematically represented in Figure 3, the 
browser 76 communicates through the intranet 16 with the proxy server 88. The communication 
is established preferably in a manner so that HTML documents intended to attract customers to 
the ATM 12 are displayed on the touch screen 30. This is referred to as the "attract mode." 
These HTML documents which are processed in the browser to produce the outputs in the form 
of screens on the touch screen 30 (and/or outputs through other output devices included in the 
machine) may originate from home HTTP server 90 which is operative to deliver the HTML 
documents to the proxy server. The home HTTP server sends the messages addressed to the IP 
port associated with browser 76, so as to cause their display at the proper ATM machine. It 
should be understood that while in this example, home server 90 is described as communicating 
with the ATMs through the proxy server 88, the server 90 may in other systems encompassed by 
the invention communicate directly with the ATMs. 
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A fundamental advantage of the system is that home HTTP server 90 may deliver 
documents selectively to the ATMs 12 connected to the intranet 16. These documents may 
include messages or material tailored to the particular location in v^hich an ATM 12 is located. 
Examples of particularly tailored screens may include bilingual messages in certain 
neighborhoods or information concerning currency exchange at various ports of entry. The 
material or messages could include advertising for various products or services or other material 
targeted to particular machine locations. The JAVA applets and JAVA script are loaded from a 
central location providing selective software distribution in the ATMs which may also be used to 
tailor the ATM to its environment by causing it to access documents which include material 
intended to be useful in that location, and which is not provided in documents delivered to at 
least some other machines in the system. 

Systems of the present invention may be configured to have selected machines access 
HTML documents at different addresses, so that the particular documents accessed include the 
material targeted to users of the particular machine. Alternatively, a machine may communicate 
machine data indicative of its identity and/or location to a server. From the machine data, and 
data stored in a data store in connection with the server, the server operates to deliver the 
documents including the targeted material. This may be accomplished by assembling 
subdocuments, or otherwise, to generate the documents that will be delivered to the browser of 
the particular machine. In addition it should be understood that while in the embodiment shown 
the HTML documents are accessed through a server of an institution associated with the 
machine, the documents used for the attract mode may be accessed from other servers operated 
by other entities. 

21 



The touch screen 30 in this exemplary transaction sequence displays a screen which 
includes an icon which indicates in one or more languages that to commence a transaction a user 
should touch the screen. If a user touches the screen in the area of the icon an input signal is 
generated. The input signal or HTTP message is transmitted through the browser 76 to the home 
address of the home HTTP server 90 to which the ATM 12 is currently in commxmication. The 
message generated back to the home HTTP server is represented by the arrows directed from the 
browser 76 to the intranet 16, from the intranet 16 to the proxy server 88, and from the proxy 
server to the HTTP server 90 in Figure 3. 

In response to the home HTTP server 90 receiving the message indicating that a customer 
has touched the icon on the screen, the home server is operative responsive to the address 
accessed to send a message through the proxy server 88 (or in other embodiments directly) to the 
browser 76. This message preferably includes an HTML document which when processed 
through the browser produces a screen instructing the customer to insert their card into the card 
reader mechanism 38. The HTML document flow which is represented graphically in Figure 4, 
preferably also includes embedded JAVA script or other instructions which operate in the JAVA 
environment to communicate a message to the JAVA applet responsible for enabling the card 
reader in the device application portion 84. In one preferred embodiment the instructions provide 
a pointer or tag to the applet which executes responsive to receipt of the document instructions. 
Of course in other embodiments other software and approaches may be used. 

As shown in Figure 5, in response to the embedded JAVA script activating the JAVA 
applet associated with the enable card reader function, the JAVA applet in the device application 
portion 84 communicates with the device server 92. The device server 92 includes a device 
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server program 98 which in the preferred embodiment is a JAVA program that enables 
communication with the JAVA applets and the device server application 100. The device server 
92 further preferably includes a monitor software application 102 which is operative to monitor 
device operation instructions. The monitor software minimizes the risk of fi*aud or abuse in a 
maimer later explained. 

Returning to the sample transaction, in response to receiving the enable card reader 
message from the device application portion 84, the device server 92 is operative to generate a 
message through the intranet 16 to the device interfacing software portion 64 of the ATM 12. 
This message which comprises an HTTP record including instructions for operating the card 
reader, is directed to the IP port indicated 74 which is where the device interfacing software 
portion 64 communicates. In response to receiving this message, the software portion 64 is 
operative to send a message or messages on the control bus 50 which enables card reader 
mechanism 34. 

Continuing with the transaction as shown in Figure 6, the input of the card by the 
customer to the card reader 34 is operative to cause the card data to be read and the device 
interfacing program portion 64 to send a message to the device server 92 indicating the card data 
has been read. This message is transmitted by the device server through the intranet 16 to the 
device application portion 84. The device application portion then sends a message to the device 
server requesting the card data. The device server 92 transmits a message with instructions to 
deliver the card data from the device interfacing software portion 64 which responds with a 
message sending the card data through the intranet to the device server. The device server, if 
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there is no basis for stopping the transaction, transmits an HTTP record including card data back 
through the intranet 16 to the device application portion 84. 

In one preferred embodiment of the invention, the card input by a user or customer 
includes indicia v^hich corresponds to an address associated v^th the user in the network. In such 
an embodiment the indicia corresponds to a uniform resource locator ("URL") address v^hich 
provides information on the computer where the user information resides, as well as a directory 
or subdirectory which includes the user information and the name of the docimient or resource 
that includes the user information. The URL address may be encoded on a customer's card. The 
address may be encoded on track 3 of a magnetic stripe, in other locations v^thin the magnetic 
stripe data or through encoding other readable indicia on the card. Altematively, if the 
customer's card is a "smart" card which includes semiconductor storage thereon, the URL address 
associated with the customer may be included as part of the stored data on the integrated circuit 
chip on the customer's card. Altematively, a URL could be derived from other data on the card 
by accessing a data base in which address data is correlated with other data read from the card. 
The data necessary to derive the address for accessing documents associated with a customer 
could also be derived from inputs to input devices other than or in addition to card data, 
including for example biometric data which is input by a customer through a biometric reading 
device. Such biometric data may include for example, data corresponding to one or more 
fingerprints, data from the user's appearance or combinations thereof. 

For example and without limitation, data input by a customer such as through a card input 
to a card reader may correspond to an address for accessing an HTTP record, which may be a file 
or document which includes information which can be used for verifying the identity of a user. 
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This record could include data corresponding to a PIN number. The information may include 
biometric data corresponding to the authorized user of the card. The browser may access the 
record and use the contents of the record such as data and/or instructions to verify that the indicia 
corresponding to biometric data in the record corresponds to the biometric data of the user 
entering the card. Alternatively, input data representative of appearance, voice, other features (or 
combinations thereof) or other input data, may be used to generate one or more addresses which 
correspond to a user, and the content of the record at the accessed address used to verify that the 
user at the machine corresponds to the user associated with the record. Numerous approaches 
within the scope of the invention may be used. The information in the record corresponding to a 
user may likewise be used to authorize certain functional devices on the machine to operate for 
the user while other devices may not. For example, a user who is overdrawn may have 
information in the record accessed that prevents them from actuating the cash dispenser, while 
users who are not overdrawn may include information which enables such operation. 
Alternatively, the absence of information in a corresponding record may enable operation, while 
the inclusion of information selectively limits the operation of devices. 

Returning to the exemplary transaction, the delivery of the card data from a successfully 
read card is delivered responsive to the programming of the device application portion 84 to a 
JAVA applet associated with notifying that the card data has been entered. In response, the 
JAVA applet operates to generate JAVA script which configures the browser with the URL 
address corresponding to the data read from the card. The JAVA applet is also preferably 
operative to open a record schematically indicated 104 concerning the transaction, which 
includes the user's URL address, the time and other card data. This record in a preferred 
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embodiment may be stored in memory as data in an object in software. The object is preferably 
used to accumulate data as the transaction proceeds. The data stored in the transaction data 
object preferably includes data input through input devices by the user as well as data 
representative of operations carried out by transaction function devices. 

The record or transaction data object provides persistence through what may be several 
different transaction steps executed by the customer. The ability to use and share the data in a 
number of different operations avoids the need to derive it or obtain it from a customer more than 
once in the course of a user session involving a number of transaction steps. The use of a 
transaction data object enables applets to run largely independently, obtaining needed data from 
the transaction object. The approach also enables the record or data object to be used to produce 
an appropriate record at the end of the transaction session. This record may be stored, collected 
into a batch or delivered to selected addresses in a local or wide area network. 

As schematically shown in Figure 7, in response to the browser 76 receiving the URL 
address data, the browser is operative to transmit a message through the intranet 16 to the proxy 
server 88. For purposes of this example, the URL address associated with the card data is that of 
a customer associated with the home bank which operates system 14. As a result, the customer's 
URL address will cause the message to be directed from the proxy server 88 to the home HTTP 
server 90 and to access the corresponding document at the address therein. Alternatively, in 
other systems the connection may be made directly with server 90 without the intervening proxy 
server 88. As previously discussed, the URL address may also include data representative of the 
devices which are operative in the ATM. 



26 



In response to receiving the message, home HTTP server 90 finds the data corresponding 
to the customer's URL address data in its associated memory and delivers to the browser at its IP 
port with an HTML document. This HTML document may include a screen acknowledging the 
particular customer by name as well as with the name of the banking institution or other entity 
which operates the home bank computer system 14. 

In addition, the HTML document preferably includes embedded JAVA script which has a 
digital signature or a means to obtain a digital signature associated with the home HTTP server 
90. The script instruction included in the document in certain embodiments causes the device 
application portion to access an HTTP address on a server, which in the described embodiment is 
server 90. The HTTP address corresponds to an HTTP record which includes at least one 
instruction and preferably includes a program such as a JAVA applet or Active-X file. The 
instruction is used to operate the appropriate transaction function device. The HTTP record 
preferably includes data representative of a signature, such as a digital signature. This digital 
signature is received responsive to the JAVA script 82 and processed in the device application 
portion 84. A JAVA applet processes the digital signature to authenticate it and if it is an 
acceptable signature authorizes operation of the banking machine. In certain embodiments the 
applet may compare the signature to signature data stored in memory for a predetermined 
relationship, such as a match. 

After the applet verifies that HTTP server 90 or other accessed HTTP record has sent a 
proper digital signature, the transaction will be allowed to continue. If for some reason a proper 
digital signature has not been sent, the JAVA applet v^ll stop the transaction and return banking 
machine 12 back to the condition prior to the start of the transaction by connecting the ATM to 
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the address associated with the attract mode in home server 90. The use of signed instructions 
may be used to assure that the various transaction function devices are only operated in response 
to appropriate messages. The use of signed instructions may be particularly appropriate for 
instructions that run the sheet dispenser or otherwise provide value to the user of the machine. 

In the example it will be assumed that the digital signature received is a proper signature, 
in which case a message is returned from the browser 76 to home server 90 indicating that the 
transaction may proceed. As shown in Figure 8, in this exemplary transaction the HTTP home 
server 90 then operates to send an HTML document to the browser 76 which includes 
instructions which when processed produce a page or screen which instructs the customer to 
enter thek personal identification number or PIN. This HTML document preferably includes 
embedded JAVA instructions which operate to cause the device application portion 84 enable the 
keyboard 40 of the ATM so the machine may receive the PIN number. Such a message is 
schematically shown in Figure 8 with the JAVA script 82 signaling the JAVA applet responsible 
for the keyboard that it has been requested to enable the keyboard. In response the JAVA applet 
in the device application portion 84 sends a message through the intranet 16 to the device server 
92. The device server 92 sends a message back through the intranet to the device interfacing 
software portion 64 in the ATM. The instructions in this message causes the device software to 
enable keyboard 40. The JAVA applet responsible for enabling the keyboard is also preferably 
operative to update the transaction record 104 to indicate that the PIN was requested. 

As shown in Figure 9, the PIN entered through the keyboard 40 is transmitted in a 
message from the device interfacing software portion 64 to the device server 92. The device 
server 92 returns a message to the responsible JAVA applet in the device application portion. 

28 



The JAVA applet then operates to send a message back through the HTML document handling 
portion and the browser 76 to the HTTP address of home server 90. This message includes data 
representative of the PIN input by the customer. In some embodiments it is not desirable to 
display the customer's PIN on the screen. In such embodiments the keyboard applet may be 
operative to display a default character on the screen such as a "*" symbol or other symbol in lieu 
of the PIN digits. Further as later discussed it may be desirable to avoid transmission of PIN or 
other data through the browser, in which case PIN data may be handled as a separate HTTP 
message or in other manner to reduce the risk of disclosure. 

The software operating in connection with HTTP server 90 is then operative to either 
verify the PIN itself or to verily the customer's PIN number and account number by sending it to 
the back office 94 and waiting for a response. Alternatively, customer PIN verification may be 
carried out in the ATM through an appropriate applet. This can be done in situations where data 
on a customer's card, such as an account number, can be correlated to the customer's PIN number 
through an algorithm. The embedded JAVA script in the HTML messages may include or point 
to an address to obtain the data and/or instructions which the applet uses to perform this 
verification function, including certain encryption key data. This may include user information 
in the HTML document or other record data that was accessed in response to the user's card data. 
As shovra schematically in Figure 9, the transaction data object 104 is also appropriately updated 
by the applet to indicate the entry of the customer's PIN. 

In alternative embodiments the machine may include a biometric reader device or other 
input device to accept data from a user. The user may input data through such a device which 
may be used in lieu of, or in addition to, PIN data to verify that the user is an authorized user. 
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This may be done for example by comparing the user data input to information corresponding to 
the authorized user of the card included in a record or a document which has an HTTP address 
and is accessed by a browser or by an HTTP client application through an HTTP server in 
response to card data. Alternatively input data may be used to generate addresses for documents 
or records which are accessed by the browser or client, and which records or documents contain 
information that is used to verify the user's identity. For example, data concerning users may be 
stored in a data store in connection with an HTTP server, which delivers data from a record 
responsive to the user data, which is used to verify the user's identity. 

It should be noted that the page or screen which requests the customer to enter their PIN 
is shown generated from the home HTTP server 90. This is preferably a screen that is associated 
with the particular customer's URL address. This will be the interface of the customer's home 
bank and will be famihar to the customer. Alternatively, the customer address may access what 
may be essentially the customer's personal "home page" vidth the institution that operates 
computer system 14. As such, it is not only something the user is familiar with, but is ideally 
tailored to the user's particular transaction needs. 

Alternatively, the document(s) or record(s) which contain the customer data may be used 
to generate the addresses for other documents. The information may also be used to generate a 
document for the particular customer in the particular circumstances. This approach may be 
useful to reduce the effort associated with developing in advance a personal visual page or 
document for each customer. 

Approaches for accomplishing this may involve including various types or categories of 
user information in the document(s) or record(s) that pertain to a particular customer. This may 
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include information such as gender, related persons, account types, permitted transactions, 
customer preferences, customer interests, account balances, previous oflfers declined or accepted 
and other information. This customer information can be used by an appropriate applet among 
applets 86 to address and/or develop an appropriate document for the browser to access based on 
the customer "profile". In addition, the profile applet may take into consideration the transaction 
devices present in the particular machine, information on which is stored in a data store in the 
machine or elsewhere in the system, as well as other factors such as the day of the week and time 
of day based on a system clock. In this way the machine determines the appropriate document to 
access or generate for the particular customer under the particular circumstances. 

The logic used in the profile applet may act to cause documents to be built or accessed for 
the customer which includes transaction options based on the customer information, information 
about the terminal and other factors. The profile applet may operate to offer transaction options 
or information selectively based on the customer information. For example, the operator of the 
machine may offer incentives, premiums, additional transaction options or advertising 
information selectively to customers. Certain types of customers of the institution operating the 
machine may receive screen outputs with options that encourage them to do more business or 
different types of business with the institution. Likewise, customers that are identified as 
customers of foreign institutions may be provided with incentives to do business with the 
institution operating the machine. 

The profile applet may operate to cause the computer to access other documents in other 
servers, such as stock market data, and selectively provide it to customers. It should be 
understood that the profile applet may operate to determine an address or generate documents to 
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produce initial display screens of a transaction sequence. The profile applet may also operate to 
provide information or access or produce documents to generate visual outputs to the customer at 
other points in a transaction or between transactions. This may further be used in systems in 
which the operator of the machine is able to sell paid advertising to third parties and then access 
the HTTP records such as HTML files for those third parties' products or services. Such 
accessing may be done based on a periodic or other basis, but may be done effectively by 
selecting the HTTP record to access in response to the profile of the particular customer. 

The continuation of the transaction flow for this exemplary transaction by a customer of 
the institution that operates computer network 14, is schematically shown in Figure 10. The 
home HTTP server 90 is operative in response to the customer inputting the correct PIN to send 
HTML documents to the HTML document handling portion of the software in the computer 
which operates the ATM. These messages may include information used to generate screens 
which prompt the customer to select a transaction. For purposes of this example, it will be 
assumed that the customer inputs at the touch screen 30 a selection which corresponds to the 
dispense of cash, which is a common transaction at an automated banking machine. 

The selection of the customer through the input device of the touch screen is 
communicated back through the HTML document handling portion which communicates an 
HTTP message to the home HTTP server 90. Server 90 then responds by sending another 
HTML document to the banking machine which prompts the customer to select an amount. 
Again the customer may input a selection on the touch screen which indicates the amount of cash 
requested by the customer. This HTTP message passes through the HTML document handling 
portion and the browser 76 to the home server 90. 
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In response to the receipt of amount data from the customer, the home server 90 is 
preferably operative to communicate electronically with the back office 94 to verify that the 
customer has the amount requested in their account. This is preferably accomplished through a 
Common Gateway Interface (CGI) 106 which is in operative connection with the home server 90. 
For purposes of this transaction it will be assumed that the back office 94 indicates that the 
money is available in the customer's account and sends a message through the CGI 106 to the 
home server 90 mdicating that it may proceed. 

As schematically represented m Figure 1 1 , the home server 90 then operates to send a 
document back to the HTML document handling portion in the ATM software. This message 
preferably will cause information to be displayed on the screen which advises the customer that 
the transaction is being processed. In addition the HTML document returned preferably includes 
JAVA script which include embedded instructions which are executed and communicated to a 
JAVA applet associated with the operation of the sheet dispensing mechanism 42. 

The document returned from the home server 90 may include advertising or other 
information instead of or in addition to the customer message. The document returned may also 
include an instruction which causes the machine to access or generate another document. These 
instructions may invoke methods in the profile applet which depend on the properties associated 
with the customer, the machine, the current time and/or other circumstances. This enables 
accessing documents that provide promotional messages such as advertising or other information 
to the customer while the customer is waiting for the machine to operate. It should be 
understood that these documents may be accessed anywhere, including from the Internet. This 
makes it possible to selectively present a wide range of materials to customers. It also enables 
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operators of ATMs and other transaction machines to present advertising to customers, on a 
broad basis, or targeted to categories of customers or even targeted to individual customers on a 
segment of one basis. This could be advertising of the machine operator such as a bank, or 
advertising pertaining to virtually any type of goods or services. The advertising may also be 
selectively presented based on the particular transaction device being operated, the amount of 
funds involved or other parameters. The HTML documents also enable the presentation of video 
and sound to the customer which may enhance the effectiveness of promotions. 

The message to the JAVA applet in the device application portion 84 of the software to 
initiate operation of the sheet dispenser results in generation of a message to the device server 92. 
The message to the device server 92 to dispense cash is preferably analyzed by the monitor 
software 102 to check to see if the message is appropriate. For example the monitor software 
102 is preferably operative to assure that the amount of cash being requested does not exceed a 
preset amount. It can also optionally check to verify that the amount provided to this customer 
within a prior period has not exceeded an amoimt. This may be done by the device server 
sending a message to the back office which includes the card data it has previously received from 
this customer. This message may pass through server 90 and its associated CGI, or other 
connection. Assuming that the dispense instruction is not prevented by a message from the back 
office or the monitor software, the device server 92 is operative to send a dispense message to the 
device interfacing software portion 64 in the ATM, The software portion 64 is thereafter 
operative responsive to the message to operate the sheet dispensing mechanism 42 to dispense 
the amount of cash requested by the customer. 
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The monitor software 102 preferably performs additional functions in the device server. 
For example, government regulations or good business practice may require limiting the size and 
amounts of deposits which may be made into an ATM. This may be advisable to prevent "money 
laundering" or other suspicious activities. The monitor software preferably operates to limit the 
amount of any single deposit to below a set limit. It fiirther operates by communicating with the 
home bank back office system 94 to prevent a series of deposits withm a preset time fi-om 
exceeding a certain limit. The monitor software may also work in connection with the proxy 
server to limit certain transactions that may be carried on at the banking machine responsive to 
instructions from foreign servers as later discussed. 

It should be noted that in a preferred embodiment of the invention the JAVA applet 
which is operative to send the message which causes cash to be dispensed, works in connection 
with another applet which controls the mix of bills dispensed to a customer. Many automated 
teller machines have the ability to dispense two or more denominations of currency bills. It is 
desu-able to control the mix of bills dispensed to a customer to suit that which is available in the 
machine and to avoid running out of one denomination of bills before the other. The bill mix 
applet is preferably operable to conti-ol the bill mix in accordance v^th the desires of the 
institution operating the ATM machine as well as is in accordance with the ATM machine's 
capabilities. Alternatively, a JAVA applet for controlling bill mix may reside in device program 
70 in device interfacing software portion 64. 

As will be appreciated by those skilled in the art, the particular JAVA applets and/or 
configuration data in the machine may be selectively loaded from the home server 90 at machine 
start up or at other times. Because the applets and configuration data may be selectively 
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delivered to particular machines, the machines may be tailored specifically to the particular 
ATMs currency dispensing and other capabilities. For example, the ATM may be configured so 
that certain applets or groups of applets must be present to enable the machine to operate. One 
approach to loading such data or programs is to provide address values in the terminal software 
to indicate where the needed instructions to acquire the applets or data may be obtained. If the 
applets or groups of applets are not akeady present in memory of the ATM terminal at start up, 
the software is operative to access the system addresses for the documents which contain the 
required records or instructions which will cause the machine to load the required records. The 
browser may be used to access the addresses and the software loads data corresponding to the 
instructions from the accessed documents into a memory in the ATM terminal so that the 
terminal has the required applets and data. Such document addresses may be accessible through 
the home server 90. Alternatively the addresses may be on a separate development server 
connected to the intranet 16. In this way each transaction machine is able to load the applets and 
data which include the operative code it needs to operate the transaction devices in the machine. 
Alternatively, the documents may be provided through a development server or other server that 
is accessible to the machine through a wide area network. The documents may be provided on 
the development server to provide the machine with instructions on how to acquire the operating 
code to carry out a wide variety of fimctions. The instructions may direct the machine to acquire 
the necessary data and code from addresses accessible through HTTP servers by an HTTP client 
in the machine. The data and code can be acquired responsive to instructions in one or several 
documents. The machine may also require that the applets loaded in this manner be signed 
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applets including digital signatures or other authenticating features to achieve operation of certain 
devices in the machines. 

Alternatively, embodiments of the invention may acquire the necessary applets and data 
from a remote data store. The data store preferably includes the data and/or programs that enable 
the machine to operate as desired or have instructions on where the machine may acquire the 
necessary instructions and data for operation. The data may be accessible from a data base 
server. The transaction machine addresses a query to the database server. The query includes or 
is accompanied by indicia from the machine which identifies the machine. This may be the 
particular machine such as a machine number, and/or may include indicia representative of the 
type or functional device capabilities of the machine. 

The data store preferably includes records which have the data or programs that are to be 
transmitted to the machine. In response to the query to the server, the server retrieves records 
from the data store and responsive thereto delivers one or more messages to the HTTP client in 
the transaction machine. This message(s) includes the configuration data or applets to enable the 
machine to operate in the manner desired or may include instructions which indicate how the 
machine is to acquire such programs from servers connected in the system. 

In the example shovm the configuration server and data store may operate on the same 
computer as home bank server 90. In other embodiments the database server may reside 
elsewhere in the networks to which the machine is connected. 

An advantage of the machines and systems which employ such features is the flexibility 
to change the operation and customer interface of the machine to respond to changing conditions. 
This may include a change in a transaction function device. Conditions may change so that 
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certain transactions are limited or are not available. For example, a machine may normally 
accept deposits but its depository is full. In that situation the machine may change the documents 
it accesses to present messages to users through its output devices so that the deposit option is no 
longer offered. This can be accomplished by the applets and data loaded into the machine 
initially, which provide for instructions v^hen such event is sensed. Alternatively, the machine 
programming may be modified by loading new applets and/or data from an HTTP server 
responsive to its then current status. This may be done responsive to a query to a database server 
which includes or is accompanied by data representative of the changed conditions or capabilities 
of the machine. In response the server delivers the applet(s), data and/or instructions which will 
operate the machine in the modified mode. 

This approach eliminates the situation v^th conventional transaction machines where the 
static interface presentation on output devices offers a transaction option to a customer. 
Sometimes, after the customer has made the selection an indication is given that the selected 
transactions option is not available. The approach described herein may be used with numerous 
transaction options and variations of transactions. The transaction options can be readily 
changed from the database server on a machine by machine basis or even a customer by customer 
basis as previously discussed, based on the desires of the entity operating the transaction 
machine. 

The discussion of the exemplary transaction will now be continued. In response to the 
cash dispenser 42 dispensing the requested amount of cash, device interfacing software program 
64 preferably operates to send a dispense operation message confirming the dispense back to the 
JAVA applet responsible for the dispense in the device application program 84. As represented 
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in Figure 12, the particular applet is operative to update the transaction record 104 to indicate the 
dispense of currency to the customer in the particular amount. The embedded JAVA script 
instructions which were operative to cause the dispense of currency to the customer, also 
preferably include instructions to send a confirming message back to the home server 90 that the 
dispense is complete. The receipt of the dispense operation message indicating the cash was 
dispensed causes the JAVA applet to configure the HTML document handling portion to send a 
device response message back to the home server. The home server then is preferably operated 
in accordance with its programming to indicate to the back office 94 that the customer received 
the amoimt of funds dispensed. This amount is deducted from the customer's account in the 
records maintained by the back office system. 

Generally during a transaction it is common to ask the customer if they v^sh to have a 
receipt for the transaction. This may be done at various times during the transaction flow. In the 
present example, after the cash has been dispensed the customer operating the machine is sent 
such a message as reflected in Figure 13. The home server 90 is operative to send an HTML 
document which includes a screen asking the customer if they would like a receipt. This 
message is displayed as part of a page on the touch screen 30 responsive to receipt of the 
message through the browser 76. Altematively the document may be generated by the machine. 
In response to the customer indicating that they do or do not want a receipt, a message is returned 
to the home server. Again it should be understood that the screens displayed to the customer are 
preferably those that the customer is accustomed to from his or her home institution, and may be 
a part of his or her unique home page. 
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Assuming that the customer wishes to receive a transaction receipt, the home server 90 
operates as shown in Figure 14 to send a document back to the ATM with embedded JAVA 
script indicating that a transaction receipt is to be printed. These instructions in JAVA script are 
communicated to the device application portion 84 which sends a TCP/IP message through the 
intranet to the device server 92. The device server 92 in tum communicates a message with 
instructions to the device interfacing software portion 64 in the ATM. In response to receiving 
the message, software portion 64 is operative to cause the printer 46 to print the customer's 
transaction receipt. The JAVA applet responsible for enabling the printer is also preferably 
operative to update the transaction data object or record 104. As later discussed, the applet 
which controls the printing of the receipt may obtain the data used in printing the receipt from the 
transaction data object. 

It should be understood that even if the customer does not wish to have a receipt it is 
desirable to print a record of the transaction in hard copy through the journal printer 48. This 
may be accomplished in response to imbedded instructions which are part of the same document 
from the home server 90 which causes the transaction receipt for the customer to be printed, or 
may be part of a separate document which indicates that the customer has declined the option to 
receive a transaction receipt. Altematively, the joumal printer may be actuated responsive to 
other applets such as the applet which causes the dispense of cash, or in another manner chosen 
by the operator of the ATM. As will be appreciated from the foregoing description the operation 
of the preferred embodiment of the ATM is inherently flexible and programmable to meet the 
needs of the system operator. 
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As shown in Figure 15 upon completion of the printing of the transaction receipt, the 
software portion 64 is preferably operative to send a device operation message to the device 
server 92 which is indicative that the requested device function was carried out successfully. The 
device server 92 is operative to send a corresponding device operation message to the device 
application portion 84, and in the preferred embodiment to the particular JAVA applet 
responsible for the printing of the receipt. The JAVA applet in turn configures the HTML 
document handling portion to generate a message back to the home server in the form of a device 
response message to indicate that the receipt was printed for the customer. 

Having received cash and a receipt, the customer is then prompted by a display screen 
generated from an HTML document from the home server 90, to indicate whether they wish to 
conduct another transaction. The visual page or screen prompting the customer in this regard is 
displayed on the touch screen 30. For purposes of this example it will be assumed that the 
customer does not want another transaction and a message to that effect is returned through the 
HTML document handling portion back to the home server 90. 

As shown schematically in Figure 17 in response to receiving a message that the customer 
is done, the home server 90 is operative to send a "go home" message to the ATM. This message 
preferably includes an HTML document which produces a screen display thanking the customer. 
This message also preferably includes embedded JAVA script which calls the JAVA applet 
which eventually returns the HTML document handling portion of the ATM back into 
connection with the URL address on the home server 90 or other address which provides the 
documents that are used to output the messages for the so called "attract mode". It should be 
remembered that the script in some embodiments may operate to cause a message to be sent from 
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the document handling portion to an address on the home server which causes a corresponding 
HTTP record including the instructions comprising the desired applet to load. 

As schematically indicated in Figure 18, the "go home" command applet is operative to 
configure the brov^ser 76. After the HTML document handling portion is configured by the 
JAVA applet to return home, the JAVA applet may be configured to deliver to home server 90 
information fi^om the transaction record 104 concerning the transaction that v^as just completed. 
Because the exemplary transaction v^as with a customer of the institution that operates the 
computer system 14, all the data concerning that transaction should already be recorded in the 
back office 94. However it v^ll be appreciated that this will not be the case if the transaction was 
conducted in response to messages from a server operated by a different institution. Thus, all or 
a portion of the information from the transaction record 104 may be delivered in response to a 
"go home" command to the home server 90 and through the CGI to the back office system 94 
where it can be identified as duplicate information and discarded. This may be done using 
remote method invocation (RMI) to pass or deliver the object to server 90 and then transmitting 
the data through messages from the server to the back office or through messages or other 
techniques. 

Of course in other embodiments transaction information may be stored in a database for 
extended periods rather than being returned after each transaction. Alternatively the ATM 12 of 
the present invention may include applets which are operable to deliver transaction record 
information to addresses other than that of the home server, if that is desired by the operator of 
system 14. 
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The operation of the computer system when a "foreign" user uses the ATM 12 is 
graphically represented with regard to Figures 19 through 24. A transaction with a foreign user 
who is not a customer of the institution that operates ATM 12 and computer system 14, will be 
operated under the control of the home server 90 and will proceed in the manner of the prior 
5 example through the point where the customer inputs their card. The customer inputs a card 

having indicia corresponding to a URL address that does not correspond to the home server 90. 
The HTML document handling portion is operative to configure a message addressed to access a 
URL address that corresponds to the indicia on the customer's card or other address responsive to 
such indicia. This message is deHvered to the proxy server 88 which in turn passes the message 
1 0 O to the wide area network 1 8. From the wide area network the message proceeds to the foreign 
server corresponding to the customer's URL address. For purposes of this example the foreign 
server corresponds to server 96 which is connected to the Internet. 
m In the preferred embodiment of the invention proxy server 88 includes screening software 

H graphically indicated 107. Screening software is preferably operable to check addresses to which 
1 5 messages are being directed by the ATM and to selectively prevent the sending of messages to 
^ particular addresses. This serves as a "fire wall" and is desirable for purposes of preventing fraud 
in the system. 

As shown in Figure 20, the foreign server 96 is preferably operable to communicate 
HTTP messages, including HTML documents, to the ATM 12 back through the wide area 
20 network 1 8. This may be done using a secure socket connection ("SSC") so as to minimize the 
risk of interception of the messages. Of course other techniques, including encryption message 
techniques may be used to minimize the risk of interception of the messages. 
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As schematically represented in Figure 20 the response document from foreign server 96 
preferably includes embedded JAVA script is representative of or corresponds to a digital 
signature v^hich identifies the foreign server 96. This may be accomplished by loading an HTTP 
record including a signed applet, as previously discussed. An applet in application portion 84 in 
the ATM preferably operates to verify the digital signature in the manner described in the prior 
example, and sends a message indicating that the transaction has been authorized. The digital 
identity of the foreign institution v^U be stored in memory in the ATM and eventually recorded 
in the back office 94. 

It should be noted that the HTML documents from the foreign server 96 produce the 
visual pages or screens of the foreign institution which the foreign customer is accustomed to 
seeing. These pages may correspond to the foreign user's "home page" which are tailored 
specifically to the needs of the particular user. 

Figure 21 shows an example of a document accessed through the foreign server 96 to the 
ATM 12. The document from the foreign server may include embedded JAVA script which 
enables operation of the JAVA applets in the manner previously discussed to operate the devices 
36 in the ATM. As shown in Figure 21 the TCP/IP messages to the devices from the JAVA 
applets pass from the device application portion 84 to the device server 92, and the instructions 
therefrom to the device interfacing software portion 64 in the ATM. Device operation messages 
take a reverse path. As these messages pass through the device server 92, monitor software 102 
monitors them to minimize the risk of fraud or abuse. 

As indicated in Figure 21, the documents from the foreign server 96 may be operative to 
display at the touch screen 30 a request for the customer to input their PIN. The embedded 
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JAVA script instructions would, as in the sample transaction previously discussed, include 
instructions that enable the keyboard 40 to accept the customer's PIN. As in the prior example, a 
transaction record 104 which includes a shared data object concerning this transaction would be 
opened by the device application software portion. As previously discussed, provisions may be 
made to prevent the passage of PIN data through the browser if desired. 

Figure 22 indicates the return of the device operation message and PIN data to the JAVA 
applet, which in turn transmits the data back to the foreign server 96 through the wide area 
network 1 8 using the secure socket connection. From this point the transaction proceeds 
generally as previously described, except that the foreign server 96 sends the HTTP records, 
including HTML documents, and receives the messages from the document handling portion of 
the ATM. The foreign server 96 includes the JAVA application software necessary to include 
the embedded JAVA script in the documents that are sent to the ATM to operate the devices 36 
in the machine. 

As the foreign server 96 operates the machine, the monitor software 102 in the device 
server 92 is operative to monitor the messages in the manner previously discussed. Such 
monitoring would for example, operate to prevent the dispense of unduly large amounts of 
currency out of the machine. The monitoring software may also operate to restrict certain foreign 
institutions to a subset of the transaction machine devices or capabilities. This is done based on 
data stored in memory which limits the devices or activities that can be carried out from 
documents at certain addresses. This may be achieved for example through the use of code plug- 
ins which implement a class of the transaction objects which limits the operations that can be 
performed. For example, the operations which enable connection to the foreign server may 
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instantiate the objects which provide specified limited capabilities for messages received from 
the foreign server. This may for example limit the amount of money dispensed, prevent 
operation of a check acceptance device^ limit the dispense to printed documents such as tickets, 
prevent operation of the cash dispenser or limit use of the machine in other appropriate ways. 
This may be done based on the addresses or portions of addresses for documents. 

If the capabilities of the machine to the foreign customer are limited, the foreign customer 
may be provided with a visual interface from the foreign bank based on the transactions the 
machine can perform and that the owner of the machine will allow. As a result the documents 
accessed at the foreign bank server may be a variation of what the customer would be provided at 
a machine operated by the foreign bank. This could be based on documents specifically 
developed for operating foreign machines, or could be a variant of the usual foreign bank 
interface with visual indications that certain transactions are not available. In some instances the 
interface may indicate that some transactions are available with an associated service charge. 

The ATM of the described embodiment may enhance security by limiting the addresses 
that the browser may access. This may be done by maintaining a list in the memory of the 
machine. This list may be maintained in HTTP record(s) (including documents) accessible 
through the home bank's intranet. The machine may access the record periodically and update 
the memory data. This record may itself require a digital signature corresponding to a signature 
in the terminal memory before the data vrill be loaded into terminal memory. This information 
may also include the instructions and information for the ATM to verify that the messages it 
receives by accessing documents on the foreign server are genuine. This may include digital 
signatures which when transferred using public key or private key encryption techniques verify 
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the messages as genuine. The machine checks to be sure the signature in the records accessed 
from the foreign server corresponds to the digital signature for that address stored in memory, 
and enables operation of transaction devices, such as the cash dispenser, only when such 
correspondence is present. Of course various approaches to verifying and encrypting messages 
may be used in various embodiments. As used herein signatures or signed record encompass any 
indicia which is included in or is derivable from a record which is indicative that it is authorized. 

As can also be appreciated from the foregoing disclosure, the foreign server 96 may 
communicate to the user through the touch screen in a language that is different from that 
normally used by the customers of the institution that operates the computer system 14. As a 
result the HTML documents may display requests to dispense currency of a type or in an amount 
which is not included in the ATM. To accommodate this situation an applet is preferably 
included in the device application portion 84 to deal with requests for foreign currency. The 
foreign currency applet causes the ATM to send a message back to its home server for purposes 
of calculating a closest amount which may be provided to the customer in the available currency 
in the ATM which corresponds to what the customer requested. As will be appreciated, this 
applet will be operative to call the particular function address within the home server 90 that is 
capable of providing this function. When the dispense is made the applet is also operative to 
indicate to server 96 that the amount dispensed differs somewhat from the amount the customer 
requested. Of course in other embodiments, other approaches may be used. Altematively an 
applet in the machine may generate visual displays that show equivalents in local currency when 
foreign currency amounts are displayed or processed. This may include presenting both amounts 
on visual displays presented to a user. 
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As represented in Figure 23, when the foreign customer has completed their transactions 
as indicated through the touch screen 30, the foreign server 96 is operative to send the "go home" 
message back to the ATM. The receipt of this message is operative in the manner previously 
described to cause the device application portion 84 to operate responsive to the embedded 
JAVA script instructions to configure the HTML document handling portion to cause the 
browser 76 to reestablish communication with the home server 90, or other designated document 
address. 

As indicated in Figure 24 the applet in the device application portion 84 which processes 
the "go home" message is preferably operative to reconnect to the home server 90 as well as to 
send the transaction record information in record 104. This transaction record information which 
is preferably packaged in a data object, includes the customer name, the foreign institution name, 
digital identifier, amount information concerning amounts dispensed, transferred or deposited, 
and all other pertinent transaction data. The transaction data is used by applets in performing 
transaction steps in which any portion of the data is required. At the completion of the 
customer's activity at the machine an applet provides a transaction data message which includes 
at least a portion of the collected data. This data is communicated from server 90 through the 
CGI 106 to the home bank's back office 94. This information is stored in the back office for later 
use for purposes of settlement with the foreign bank operating the foreign server 96. 
Alternatively or in addition, transaction data may be recorded in the terminal in memory as well 
as in hard copy on a journal printer. Transaction data may be stored for downloading in a batch 
or by passing objects including data fi-om many transactions. Batch data may be communicated 
at times and to addresses as may be stored in memory in the terminal configxaration data. 
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An advantage of embodiments of the invention is that transaction data may be delivered 
to addresses in a local area network or in a wide area network such as the Internet. This 
facilitates conducting wide varieties of transactions and enables directing messages related to 
tracking use (such as for electronic purse type smart cards) or for settlement of various 
transaction types to a selected system address. 

It will be appreciated that the described embodiment of the automated banking machine 
and system of the present invention provides the advantage that when the machine is connected 
to a wide area network such as the Internet^ customers are able to carry out their banking 
transactions virtually anywhere in the world. Further, despite the broad capabilities of the 
system, because the machine may be monitored locally, both in terms of connection and activity, 
the risk of fraud is minimized. 

Embodiments of the invention may include a further feature to facilitate access to 
documents in the network to which the machine is connected. This feature is operative to 
determine if an HTTP record such as an HTML document or other item is accessible at an 
address for downloading before the computer will attempt to access the record. This avoids 
transaction time outs that might otherwise occur as a result of inability to access a record due to 
the server through which the record is normally accessed being down. Other embodiments may 
consider both the size of the record and the transfer rate and determine that a transfer speed for 
the record is not sufficiently rapid, so that an alternative record should be transferred. 

In one embodiment this feature is achieved through use of a separate program or applet 
which checks to see if a server that the computer will subsequently want to access is alive. The 
applet operates responsive to receiving an address or portion thereof, to which a connection will 
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be made. The applet operates to make a socket connection to the address and loads a small but 
sufficient amount of the record or otherwise operates to determine that the server through which 
the record must be accessed is alive. In response to the applet verifying the operation of the 
remote server, or otherwise determining that conditions indicative that the record may be 
accessed or loaded, the computer then operates so that the browser or similar software 
component is enabled to navigate to the address at the appropriate time in the transaction 
sequence. If the applet is unable to detect that the remote server is alive, or determines that it 
does not appear the record may be successfully accessed or loaded, steps may be taken to access 
alternative addresses or to discontinue the transaction. Alternative addresses to access may be 
based on data stored in the memory of the terminal or may be obtained by accessing documents 
either locally or remotely which include data from which alternative addresses may be obtained 
or derived. Alternative addresses are similarly checked to make a determination that the records 
can be accessed before attempts are made to access the alternative records. This approach avoids 
delays in carrying out transactions. 

Alternative embodiments may employ other approaches to determine if desired HTTP 
records such as HTML documents may be successfully accessed and/or downloaded adequately 
before the browser providing the customer interface attempts to access the document. Such 
embodiments may consider in determining whether the document can be successfully accessed, 
the transfer speed or other conditions related to system operation or document content. For 
example, the applet which tests to determine that the HTTP record can be accessed, or a further 
applet, may determine the transfer rate at which the record can be transferred to the computer. 
The rate at which the data can be transferred may be compared to data stored in memory, and if 
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the rate is slower than the data representative of the desired stored rate an alternative record is 
accessed. This may be for example an HTML document stored locally in the machine. Other 
embodiments may include programs which consider the size of the HTTP record and the transfer 
rate in determining a transfer speed. Such programs then determine if the record can be 
transferred fast enough to suit the parameters established in the configuration in memory, and if 
not, alternative addresses are accessed. Such alternative records may be similarly tested for 
transfer speed before being transferred. 

Programs may also consider other factors in deciding to access a particular address, such 
factors may include for example day and time information, or information from sensors such as 
sensors in a floor indicating that other persons are waiting to use the machine. In this way access 
to documents that have extensive outputs which may tend to prolong transactions can be avoided 
even when records can be loaded at an adequate speed. 

While the described embodiment of the automated banking machine and system of the 
present invention is shown with regard to a particular type of machine that is made specifically 
for connectibility to local or wide area networks, conventional automated banking machines may 
also be adapted to include such capability. Specifically the HTML document handling portion 
and device application portions may be included vdth other conventional software which 
operates within an automated banking machine. This enables such ATMs to operate either in the 
conventional proprietary network or as part of a wide area network. In addition, automated 
banking machines may be configured to operate their devices through the device interfacing 
software portion of the invention or through a different software interface when operating in a 
conventional network. Such machines may switch to requiring device messages to be passed 
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through a device server when operating under the control of a server within the wide area 
network to mamtain security within the system. In this way a single ATM could operate in 
proprietary networks in the manner of current ATMs as well as in the network configuration of 
the system of the invention, 
5 Alternative embodiments of the invention operate to communicate transaction messages 

used in a proprietary ATM network. This may be accomplished by using a CGI in connection 
with either the HTML docimient handling portion of the ATM or the HTTP home server or other 
server. The CGI operates in connection with a message conversion program and database to cull 
the necessary data from the HTML documents and response messages and generate the defined 
1 0 '=!f transaction request messages appropriate for the proprietary transaction network. Likewise, the 
Ifj message conversion program and CGI operate to receive function command messages from the 
01 proprietary network and convert them and generate appropriate HTML documents and/or TCP/IP 
messages for use by the ATM. Because these proprietary network formats are defined and the 
data necessary to produce and interpret the messages are known, the use of the ATM 12 directly 
15 ij, in a conventional proprietary ATM network is achieved. 

m Conventional ATM transaction messages are defined layout messages that do not include 

HTML documents on HTTP messages. An example of known conventional messages used to 
operate ATMs are Diebold 91 X messages. Such messages generally involve transmission of a 
request message from an ATM in a defined layout including customer input data (account/pin) 
20 and an indication of the type and amoxmt of transaction requested. The request message is 

received by an ATM host computer which sends back a response message with a defined layout 
which includes an indication whether the transaction is authorized. The ATM then returns 
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another message to the host computer indicating whether the machine was able to carry out the 
transaction. The messages used in such conventional proprietary networks generally occupy 
relatively little band vddth. 

In connecting the ATM of the invention to such a network, a server is provided. The 
5 server is in operative connection with a memory which includes a relational database which 
holds the message conversion and document creation data. In one configuration, the server is 
connected to the document handling portion through a network, or may reside on the computer of 
the ATM. The server produces the documents which the browser accesses and which include the 
transaction device instructions. The server (or a connected server) communicates the 
1 0 O conventional messages v^th the host. One server may provide an interface for several ATMs 
-^f connected to it in a LAN, or alternatively, each ATM may have its own server operating therein. 

The ability of ATM 12 to communicate in a proprietary network also enables operation of 
m the ATM in a manner in which the interface is generated by a user's home institution in the 
H manner previously described, but in which transactions are authorized through messages directed 
15 through a proprietary ATM network. This achieves the security of using the proprietary network 
|:f while providing the customer with the advantages of the familiar home bank interface and/or 
"personal home page" interface. 

In such a configuration the ATM transaction function devices may be operated in a 
conventional manner in response to conventional ATM transaction messages such as Diebold 
20 9 IX messages, in the proprietary network. The customer output devices, such as the screen (and 
speakers if provided) communicate through a browser connected to a local or vdde area network. 
The browser accesses documents to prompt a customer through operation of a transaction, but the 
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documents do not include instructions which cause operation of devices such as the cash 
dispenser. 

In one configuration the browser may be operated by the computer in response to the 
status of devices in the machine, as the devices are operated in response to conventional ATM 
5 messages. In this manner the browser may be navigated to selected addresses, including 

addresses which are associated with the customer based on customer input data. However, as the 
documents received by the browser vvill not operate the transaction function devices, there is less 
need for security measures in accessing documents. As a result, the customer may still operate 
the machine in response to a familiar and unique interface, and marketing information such as 
10 O advertising or other material may be presented in the transaction sequence. 

In other embodiments machines may perform some device functions based on 
m conventional messages, while others may be performed in response to instructions in HTML 
fli documents or other HTTP messages. For example HTML documents may provide considerable 
^ data for use by printers or other output devices. Some embodiments may access documents with 
1 5 1'] instructions, but may ignore some and act in response to others. The approach may be selected 
p by the systems operator by configuring the software based on their requirements. 

A fiirther advantage of the system configuration of one preferred embodiment is that it 
has enhanced flexibility for communicating messages associated with the ATM. The device 
manager 68 preferably generates status messages associated with the status of devices 36. These 
20 status messages may commonly represent information about conditions which exist at the 

devices. Such messages may indicate that supplies of paper for printers or currency, are low or 
are depleted. Other messages may indicate that devices are not functioning properly. Often such 
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messages indicate that the ATM requires servicing. All such types of messages are referred to 
herein interchangeably as status or fauh messages. 

The device interfacing software portion 64 communicates through the intranet 16 using 
TCP/IP messages. While the messages associated with transactions previously described are 
directed to the device server 92, the software portion 64 may include a server and be configured 
to address fault and status messages to other addresses in the intranet or the Internet. For 
example, such fault or status messages may be directed to a software application which delivers 
messages to a service provider. Further, fault messages may be selectively directed based on the 
nature of the fault indicated. For example, fault messages indicative of a need to replenish 
currency or supplies may be directed to an address in the intranet associated with an entity who 
has responsibility for replenishing supplies. Alternatively, fault messages which indicate a need 
for other types of servicing may be directed to an address associated with an entity who can 
provide the type of servicing required. 

Alternatively, the selective dispatching of fault messages to addresses in the intranet 16 
may be accomplished by appropriately configuring device server 92. In addition, either software 
portion 64 or device server 92 may direct fault messages from the ATMs to a fault handling 
system such as to a computer operating Event Management System™ software available fi-om 
Diebold, Incorporated. Such software is operative to resolve the nature of the fault condition and 
to notify appropriate personnel of the corrective action to be taken. 

The ATM 12 may further include a software fianction to assist in diagnosing problems 
and providing remedial service. As graphically represented in Figure 2, alternative embodiments 
of the ATM 12 may include a mini-HTTP server 109 which is in commimication with the device 
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interfacing software portion 64. Server 109 is configured to receive device status messages and 
to produce HTTP records including HTML documents in response thereto, which provide data 
representative of device status to a diagnostic device 110 such as a hand held computer terminal 
Server 109 includes a CGI for interfacing vAih the device software so that a technician may 
access the information in the records accessible at the HTTP addresses related to status messages 
and input test and corrective instructions through diagnostic device 110. The HTTP records 
and/or HTML documents generated by server 109 may preferably include graphic and audio 
instructions indicative of conditions such as problems, as well as corrective action data and repair 
instructions. 

In alternative versions of the invention the functions of the mini-HTTP server 109 may 
reside in device server 92. This may be particularly appropriate where the fimction of the device 
server resides on the computer in the ATM. Regardless of where the fimction resides the use of 
the visual and audio components of HTML documents associated with maintenance and 
diagnostic messages facilitates servicing of the ATM. 

These records delivered through the mini-HTTP server include instructions that 
correspond to the status or fault conditions. Such records or documents may be accessed locally 
as previously discussed, or remotely. A technician using a hand held computer which includes a 
browser or other software operative to access the HTTP records may access the documents 
locally for purposes of maintenance, diagnosis and servicing. In some situations the customer 
interface and browser associated therewith may be used to access the mini-HTTP server, or a 
separate browser, display and input devices on the machine and intended for use servicing 
activity may be used. Altematively, the fault and status messages may be monitored from 
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terminals at locations anywhere that are connected in the network. The mini-HTTP server 
handling status and fault messages may also be configured to send an e-mail or similar message 
to a selected address whenever a particular condition or group of conditions exist. 

A further advantage of this feature is that HTTP messages may also be sent to the mini- 
HTTP server to attempt to correct problems. Such messages may include running diagnostic 
tests and receiving results. It may also include operating devices to test or attempt to clear jams 
and other malfunctions. This can often be done from remote locations. Of course, when there is 
a significant risk of unauthorized access to the server handling default or device messages, 
appropriate security measures should be taken. 

The HTTP records which indicate the status of the transaction function devices may have 
different forms depending on the software configuration and the needs of the system operator. In 
some embodiments the device status information for one or more devices may be represented by 
indicia contained within a data object. The data object may be transferred to other connected 
computers to provide the status data. The transfer of the data object may be accomplished by 
remote method invocation (RMI) for example. The data in the transferred data object may then 
be used to generate message and/or outputs desired by the system operator. This technique may 
be particularly useful when the operator wishes to connect the machine to an existing monitoring 
system and indicia included in the data object can be used to generate outputs or messages 
indicative of device status that can be processed by the existing system. Plug-ins may further be 
used to achieve communication between existing monitoring systems and transaction machines 
which have different types of status conditions or different types of message formats. This 
includes machines which have different types of transaction function devices and capabilities. 
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The technique of transferring a data object may also be used to conduct testing or 
modification of transaction function devices. For example, indicia in the data object may be 
modified by a servicer and the object passed back to the machine. The software in the machine 
may cause the transaction function devices to operate or change conditions or programming in 
response to the modified data object. This may include for example clearing a fault indication or 
causing a device to operate to clear a jam or to conduct a test. The results of such activity may be 
reflected in modified indicia in the data object which may then be transferred to the computer in 
the diagnostic terminal. Of course, the approaches discussed herein are exemplary and other 
approaches will become apparent to those skilled in the art from the description hereih. 

Figure 25 shows a schematic view of a network configuration for an alternative 
embodiment of the automated banking machine of the present invention. The embodiment 
shown in Figure 25 includes an automated banking machine specifically adapted for operating in 
connection with conventional automated banking machine systems such as systems which 
operate using Diebold 91X ATM message formats or other non-HTTP conventional format. A 
host computer 120 is a conventional ATM host which communicates using such messages. The 
host commimicates with an interface server schematically indicated 122. Interface server 122 
operates in the manner previously discussed and is in operative connection with a memory that 
includes the information necessary to convert HTTP messages that pertain to a transaction 
request to a 9 IX request message or other conventional message, which can be handled by host 
computer 120. Likewise interface server 122 and the instructions and data stored in memory are 
operative to convert a conventional 9 IX command message or other conventional command 
message from the host 120 into HTTP messages which can be used by the automated banking 
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machine to carry out the command. Similarly interface server 122 is operative to receive the 
HTTP messages v^hich correspond to the response of the automated banking machine to the 
commands and to produce a 9 IX response message or other conventional response message to 
the host. In accomplishing these functions the interface server conmiunicates with a interface 
client 124 v^hich in the preferred embodiment is a COMM plug in v^hich operates on the banking 
machine terminal under a Windows NT® operating environment. Interface server 122 also 
includes a command/status gateway 126. The command/status gateway is operative to receive 
command and status messages from the software portions handling the functional devices within 
the machine. The messages concerning the devices are used in producing transaction messages 
to send back to host 120. In addition, the command status gateway portion also produces status 
messages indicative of the status of devices which may also be communicated to the host. 

The interface server 122, command status gateway portion 126 and interface client 124 
may reside in software on the automated banking machine terminal. In this configuration the 
terminal appears to the host computer to be a conventional machine. Alternatively interface 
server 122 and command status gateway portion 126 may reside on a separate server, while the 
interface client portion 124 may reside on the terminal. This enables the interface server 122 to 
handle a number of automated banking machines by connecting the machines to the interface 
server through a network. 

The alternative configuration of the automated banking machine system shown in Figure 
25 is particularly adapted for use in coimection with existing ATM system. The machine 
includes an HTML document handling portion 128 which includes a browser which operates in 
the manner of the embodiments previously described. The HTML document handling portion is 
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alternatively referred to as a browser herein for purposes of simplicity. The HTML document 
handling portion operates in connection with a network 130 to access HTTP records in the form 
of HTML documents through servers 132, 134 and 136. For purposes of this example server 132 
will be considered the server of the home bank which operates the automated banking machine. 
The browser portion 128 is enabled to access documents of its home bank for purposes of 
obtaining content and instructions for purposes of outputting information to customers as well as 
for operating devices on the machine. Servers 134 and 136 are representative of other servers 
which the automated banking machine may be instructed to access for purposes of downloading 
documents which include information or instructions. Often such documents from non-home 
bank servers will include information which is to be presented to customers such as advertising, 
promotional material, stock quotations or other types of information. It should be understood 
that the servers 134 and 136 may be directly connected to network 130 or may be accessed 
through other networks and servers. In some embodiments such servers may be accessed through 
the Internet for purposes of providing documents to the automated banking machine. 

Document handling portion 128 includes a terminal theater software portion 
schematically indicated 138. Terminal theater portion 138 is schematically shown in greater 
detail in Figure 26. Terminal theater portion 138 includes a back stage frame 140 and a theater 
frame 142. The back stage frame 140 although it resides in the browser, is not visible on the 
screen of the automated banking machine. The theater frame 142 is a visible frame and controls 
what is shown to the customer. 

As schematically represented in Figure 25 the HTML document handling portion also 
includes a terminal director portion 144. The terminal director portion includes directors which 
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are related instances of applets which are used in carrying out particular types of transactions. 
The terminal directors generally correspond to the operation of the JAVA applets in the 
previously described embodiment. 

The automated banking machine of the alternative embodiment further includes a 
5 transaction services application (TSA) schematically indicated 146. The transaction services 
application provides security, terminal condition, terminal authorization and key management 
services within the automated banking machine. The transaction services application includes a 
function for communicating HTTP messages with the interface server 122. The transaction 
services application may also communicate through a network such as network 130 in a manner 
1 0 ^3 later explained. The transaction services application also provides a server function which 
\1 enables the transaction services application to carry out the functions of the device server 92 in 
m the previously described embodiment. 

01 The automated banking machine of the alternative embodiment further includes JAVA 

^ common device interfaces schematically indicated 148, The JAVA common device interfaces in 
1 5 the preferred embodiment are related instances of applets which control and coordinate the 
m operation of the functional devices 150 of the machines which perform transaction functions. 
The functional devices may include devices of the types described in connection with the 
previous embodiment or other types of devices which operate to carry out a function related to a 
transaction. The JAVA common device interfaces 148 communicate with the functional devices 
20 through common device interfaces schematically represented 152. The common device 
interfaces (GDIs) provide an interface that controls the electromechanical modules in the 
functional devices included in the automated banking machine. The common device interfaces 
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are schematically shown in connection with a diagnostic server 154. The diagnostic server 
operates in a manner similar to server 109 of the previously described embodiment. The 
diagnostic server 154 is useful in diagnosing status and in correcting problems with the devices 
in the automated banking machine. 

Referring again to Figure 26 the backstage frame 140 within the terminal theater portion 
138 is a component called the backstage applet 156. The backstage applet 156 is preferably a 
relatively thin component. Instructions referred to as script included in documents accessed by 
the browser selectively cause the backstage applet to notify a terminal director when an action is 
to take place in response to the instructions included in the accessed document. The backstage 
applet also operates to request that a new HTML document be accessed. The backstage applet 
also provides access to the shared transaction data object previously discussed which holds 
transaction data. 

The theater frame 142 controls the user interface as seen by the user of the automated 
banking machine terminal. Client HTML schematically represented 158 in the theater frame 142 
defines the identifying indicia associated v^th events sent to a director manager through the 
backstage applet and provides an interface to the director manager's public methods. The 
director manager schematically indicated 160 in Figure 26, has a class which resides in the 
transaction services application (TSA) 146 as shovra. The director manager class residing in the 
TSA process is operative to load the terminal directors 144 to the HTML document handling 
portion. The director manager also includes a backstage applet class that resides in the backstage 
frame 140. The backstage applet class of the director manager provides an interface for the client 
HTML to make requests on the director manager. Instructions in HTML documents can pass 
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events through the backstage applet 156 to the director manager. Such events include a request 
to authorize a transaction. Such requests may also include indications that the customer has 
completed a transaction or that a document loaded by the browser includes instructions 
requesting that the session be terminated. Other events which can be passed through the director 
manager include print events. Other events which can be passed through the backstage applet to 
the director manager include an indication that an entry was cancelled, or other defined user 
events. 

In response to receiving events the director manager of the embodiment shown responds 
to instructions in documents accessed by the browser to perform functions which include 
changing the content of the theater fi'ame 142. The director manager responsive to such 
instructions, also changes the active terminal director class. The director manager also caches 
terminal director classes for later use or loads terminal director classes and HTML documents 
from a list of available servers. The director manager also provides access to the shared 
transaction data object holding transaction data for a particular transaction. The director manager 
also sends terminal theater events to the backstage control class of the current terminal director 
and provides a screen timeout timer. Of course in other embodiments the terminal director may 
carry out other functions. 

In operation of the alternative embodiment shown in Figure 25 the terminal directors 144 
in the transaction services application 146 enables selectively accessing documents with the 
HTML document handling portion 128. The documents accessed may include instructions which 
are used to operate the automated banking machine and the functional devices thereon. The 
transaction services application 146 is further operative to communicate the HTTP messages 
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which are passed to the interface server 122 and which are used to generate conventional ATM 
messages which can be handled by the host 120. The dispensing of currency and other transfers 
of value are carried out in response to approval from the host 120, while the interface and other 
functions are controlled through instructions in documents accessed through the browser. 

In one preferred embodiment the ATM or other transaction machine communicates with 
the conventional ATM host by passing the transaction data object between the computer in the 
ATM and the interface server. This transfer is preferably accomplished by the remote message 
invocation (RMI) feature of software such as JAVA. Of course other methods for transferring 
the data object file using HTTP may be used. 

As previously discussed, the transaction data object holds transaction data. The machine 
acquires data pertinent to the transaction such as account data from a card, a customer's PIN 
number, requested transaction(s) and amount(s), and includes this data among the transaction 
data. 

Once the data needed to generate a conventional ATM transaction message is represented 
in the transaction data, the data object is transferred to the interface server. The interface server 
is in operative connection vAth a database 123 or other item holding conversion data as 
schematically indicated. The conversion data is used by the software associated with the server 
to generate a conventional ATM transaction request message to the host 120. The conventional 
message may be formatted as a conventional 9 IX message or other conventional non-HTTP 
transaction message. 

After processing the host 120 responds with a conventional response message. The 
components of the response message are received at the server and processed responsive to the 
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conversion data to produce modified transaction data in the data object. This modified 
transaction data preferably includes data indicative of v^hether the requested transaction is 
authorized or denied, as well as other data. For example, if the transaction is denied it may 
include data which is indicative of the reason for the denial. 
5 The transaction data object v^th the modified transaction data is then transferred to the 

computer operating the ATM by RMI or other transfer method. The transaction services 
application 146 operating in software receives the data object and operates the transaction 
function devices responsive to the modified transaction data. The transaction data object has the 
transaction data therein further modified by the inclusion of information concerning operation of 

10 y the devices. After the devices have operated, the transaction data object with the further 

modified transaction data is passed back to the interface server 122. The modified transaction 
S data is then used to generate a message to the ATM host. The message to the host includes data 
CI1 corresponding to the modified transaction data. Usually this message is a conventional non- 

HTTP completion message indicating whether the transaction was successfully carried out by the 

1 5 n transaction function devices . 

The format of the non-HTTP conventional transaction messages may be readily changed 
in the described embodiment. This can be achieved through the use of plug-ins. The plug-ins are 
operative to put data into, and to extract data fi*om, the transaction data object. The plug-ins 
achieves conversion between the transaction data and desired conventional non-HTTP messages. 

20 The use of plug-ins enables more readily using the ATM of the described embodiment in 
connection with varied types of conventional transaction networks. 
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Transaction data in the transaction data object is also preferably operative to have the 
computer operate the browser to access selected HTML documents. This may be done to 
indicate that the transaction is authorized or denied, as v^ell as to access specific documents 
responsive to components of the message. For example, customers of banks other than the one 
5 operating the ATM may be given certain promotions not presented to the bank's existing 

customers. The transaction data indicative of why a transaction is denied can be used to access 
documents which provide an explanation, or can encourage the customer to take other action, 
such as to take a cash advance on a credit card or to apply for a loan. 

The system schematically shown in Figure 25 is an example of an automated banking 
10 O machine system that achieves the wide variety of interface options available through the use of an 
HTML interface while preserving compatibility with existing banking machine systems and the 
m security techniques associated therewith. Of course in other embodiments alternative approaches 
fp and configurations may be used. 

A further advantage incorporated into the system schematically represented in Figure 25 
15f : is the ability to operate the software components of the described embodiment of the present 
5; invention in existing automated banking machines. As will be appreciated, the handling of 

HTML documents in conventional computers requires inputs through a QWERTY type keyboard 
as well as mouse clicks in locations corresponding to icons or other features on HTML 
documents to successfully navigate and use such documents. Conventional automated banking 
20 machines generally do not include a mouse or full keyboard. Rather conventional automated 

banking machines generally include an alphanumeric keypad similar to that used on telephones, 
as well as function keys. Embodiments of the present invention enable the operation of the 
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system with terminals which have such interfaces operate in a manner which attains benefits of 
the invention. 

Figure 27 shows an example of a conventional automated banking machine interface 162. 
Interface 162 includes an output device which includes a screen 164. Screen 164 may be a CRT, 
LCD or other conventional display screen. In the embodiment shown screen 164 is not a touch 
screen as in the previously described embodiment. A plurality of function keys 1 66 are disposed 
at locations adjacent to the screen 164. A keypad 168 is also included in the interface 162. 
Keypad 168 includes alphanumeric keys as well as certain other dedicated keys such as "cancel", 
"correct" and "ok". Other keys on the keypad are generally blank but in some instances may be 
used. 

In the operation of a conventional automated banking machine, screen data which is 
generated from information stored in the terminal memory produces defined transaction screens 
which are presented graphically on the screen 164. The screens appear in a sequence in response 
to the transaction function selected by the customer. Conventional screens also generally include 
text or graphics representative of selections that can be made by a customer. These text or 
graphic options generally includes lines or other indicia which extend to the edges of the screen 
adjacent to one of the function keys 166. A user is enabled to select the options by pressing the 
function key which is pointed to by the selection. Likewise in the operation of the automated 
banking machine a user is enabled to input the alphanumeric characters which comprise the PIN 
number as well as numeric amount information and other instructions by pressing the keys in the 
keypad 168. 
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In one embodiment of the present invention the software operated in the automated 
banking machine operates to convert standard ATM key inputs to operating system events such 
as a mouse click in a desired location or an input from a QWERTY type keyboard. The software 
components which enable carrying out this function are shovra in Figure 28-30. These functions 
include a keypad applet 170. The keypad applet 170 in the described embodiment is included 
among the applets in the terminal directors 144, The keypad applet 170 supports a subset of the 
keyboard common device interface (CDI) functionality. 

The keypad applet 170 coordinates with a keyboard command server which operates in 
the transaction services application 146. The server in the transaction services application 
conmiunicates with the common device interface for the keypad and function keys, schematically 
indicated 172. The key CDI in the preferred embodiment is a JAVA program which is referred 
to as a wrapper for the common device interface associated with the function keys and the 
keypad. 

The software fiirther includes a keyboard mapper program schematically indicated 174. 
The keyboard mapper in the preferred embodiment is in connection with a database 176 which 
stores a plurality of map sets. In the preferred embodiment the keyboard mapper is an extension 
of the keyboard class of objects used for operating the keyboard. The keyboard mapper operates 
to store sets of keymaps in the database 176, This is accomplished by reading information in a 
configuration database for the ATM to obtain the keymaps that are operated in the particular 
machine. During operation, the keyboard mapper selects one of the keymaps as the current set. 
This is done in response to the keypad applet and is based on instructions in HTTP records which 
are selectively accessed. The keyboard mapper may select keymaps responsive to instructions in 
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HTML documents loaded through the browser. The keyboard mapper is also operative to enable 
the keypad and function keys appropriate for the particular mapset selected. The keyboard 
mapper is further operative responsive to the selected mapset to translate a keypad input signal or 
a function key input signal into a respective keyboard or mouse input signal which is then 
delivered to the keyboard input stream or the mouse input stream of the operating system of the 
computer in which the software operates. 

In the preferred embodiment the mapsets are each comprised of hash tables. Keymap 
objects are stored as values in the hash tables such that each object includes the values and 
operations necessary to convert any appropriate ATM key event to an operating system input 
event. 

As can be appreciated in the case of function keys adjacent to the ATM screen it may be 
desirable to provide a mouse input to the mouse input stream that corresponds to a particular 
coordinate location for the mouse input. This is provided by the keyboard mapper using the 
selected keymap set. The various keymap sets enable the different function keys to provide 
different types of inputs to the computer operating system responsive to the HTML document 
displayed on the browser. Further the keyboard mapper causes the pressing of a selected key to 
produce an input corresponding to a mouse click at a selected x,y coordinate position on the 
screen. It should be understood that either keypad keys or function keys can be used to produce 
mouse inputs. Likev^se function key inputs may be converted to keyboard inputs. In some 
embodiments however it will be desirable to disable the mouse indicator on the screen such that 
the user does not notice a usual mouse icon. Such disabling may include in some embodiments 
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reducing the size of the mouse icon such that it is so small that it cannot be readily seen by a user 
of the machine. 

During portions of some transactions it may be uimecessary for the user to press any keys. 
In such situations some preferred embodiments of the invention operate to disable the keypad 
keys and/or function keys. Because resources of the computer are used in polling such keys for 
inputs, the cessation of such polling during appropriate times enables the computer resources to 
be devoted to carrying out other functions. This will increase the speed at which other activities 
may be carried out. This may be accomplished in some embodiments by the keypad applet 
operating to remove the key devices from a poll list. 

Figures 28-30 include schematic depictions of examples of the operation of the keyboard 
mapper and the keypad applet. Figure 29 shows an example of an input to the keypad 168. In 
this example the keypad applet 170 generally in response to instructions in an HTTP record such 
as an HTML document or other events, transmits and enables events to the transaction services 
application 146. In response a mapset is selected from the database 176 corresponding to the 
particular map name. The keyboard command server is further operative to enable the 
appropriate keys of the ATM. 

In this example, in response the customer pressing the "OK" key on the keypad ±e GDI 
generates an appropriate signal to the transaction services application. As will be noted from 
Figure 27 a "OK" key is referred to by convention as the "J" key of the ATM interface. The 
transaction services application transmits the signal generated from the pressing of the "J" key by 
the customer to the keyboard mapper 174. In response to receiving the signal, the keyboard 
mapper operates to resolve the object in the mapset corresponding to the map name which will 
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convert the function key input signal to a keyboard input signal which is recognized by the 
operating system. By calling the selected object from the mapset, a keyboard input signal is 
produced and delivered into the keyboard stream of the computer. This is represented by 
keyboard stream 178. In the embodiment shown the keyboard stream is an input to the Windows 
5 NT® operating system. The keypad applet 170 operates to sense the input through its 

corresponding key listener. Applet 170 is also operative to receive the event and may operate to 
display an icon or other graphic corresponding to what the customer has input. 

Figure 28 shows operation of the keyboard mapper in situations where the transaction 
services application operates to prevent transmitting the data input by the customer to the applet 
10 O 170. This may be desirable for example, in situations where the input by the customer is the 
\" customer's PIN or other data which is not to be displayed. In these circumstances the transaction 
S services application 146 operates to hold the data input by the customer and to send only a signal 
gl representative of a holding character, in this case a symbol back to the browser. This is done 
selectively in response to the instructions contained in documents accessed by the browser or in 
15 n other HTTP records accessed by the computer which indicates that the input by the customer 
corresponds to their PIN or other data which is not to be sent to the browser. In the example 
shown in Figure 28 only the holding character is passed through the keyboard mapper to the 
browser. In situations where the HTTP record accessed invokes methods in which numerical 
values are to be sent to the browser and/or displayed on the screen (such as the amoimt of a 
20 withdrawal transaction) the signal sent by the transaction services application to the browser is 
indicative of the numerical value associated with the key pressed. 
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Figure 30 is a further example of the operation of the keyboard mapper in this case the 
input corresponds to a function key 166. In this case the input is caused by pressing the function 
key "A" which is shown adjacent to the upper right hand comer of the screen as shown in Figure 
27. The signal generated in response to pressing the function key is passed to the keyboard 
mapper which in response to the data obtained from the data store 176 outputs a mouse input 
corresponding to a mouse click. The mouse input includes data representative of the x and y 
coordinates on the screen where the mouse click is to be provided. This mouse input signal is 
passed to the mouse stream input schematically represented 180. 

As will be appreciated to enable the automated banking machine which processes HTML 
documents to operate using a conventional ATM interface the mouse input will generally include 
coordinate locations which correspond to a location on the screen adjacent to the particular 
function key. This is because the icon, line, text or other indicia which the customer is selecting 
by pressing the key will preferably appear or extend on the screen adjacent to the key. In this 
way the customer is aware through the visual presentation what key to press to make a 
corresponding selection. A number of function keys adjacent to the screen may be operative at 
any one time. The customer may make selections by pressing a function key at one location and 
then a function key at another location disposed from the first location. This will result in signals 
being sent to the mouse stream corresponding to mouse clicks at coordinates on the screen 
adjacent to the function buttons pressed by the customer. During transactions various 
combinations of function and keypad keys may be operative and mapped to various keyboard and 
mouse inputs as determined by the selected mapsets. In addition developers may develop special 
mapsets corresponding to the particular graphics in HTML documents which are displayed. 
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In the foregoing manner keypad inputs to a conventional ATM or other automated 
banking machine keypad can be translated into conventional keyboard or mouse inputs which can 
be identified and processed in a conventional keyboard input stream or mouse input stream to a 
computer. Likewise function keys may be translated into mouse inputs at selected locations and 
delivered into the mouse input stream for processing by the computer or may be converted into 
keyboard inputs and delivered to the keyboard input stream, A further advantage of the 
described terminal configuration is that keys may be selectively disabled except when they are 
needed. This may reduce instances of attempts to improperly access the machine by pressing 
keys on the keyboard. Further as previously discussed steps may also be taken to disable keys 
when they are not needed to increase transaction processing speeds. 

A farther advantage of embodiments of the present invention is the ability of the 
automated banking machine to provide printed documents based on instructions in HTML 
documents. Such printed items may include tickets, travelers checks, money orders, bank 
checks, scrip or other types of documents. The ability of preferred embodiments to access and 
process HTML docxmients enables the printing of graphics and other indicia which can produce 
printed documents having selected appearance features and selected ornamental designs. This 
can reduce the need to utilize preprinted forms and also enables the printing of a greater variety 
of printed formats. Fxnther the configuration of some embodiments of the machine enable 
printing only selected portions of transaction information for record keeping purposes within the 
machine while providing versions including enhanced graphics or other attractive features to 
customers. 
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Figure 3 1 is a schematic representation of the operation of the system in printing forms 
using a printer in an automated transaction machine. The preferred form of the invention uses 
the WIN32 printer services which operate under Windows NT® 4.0. In the exemplary 
transaction shovra, the director manager class 180 operating in the terminal theater portion 138 
5 initiates a print receipt transaction by requesting a printer director 1 82 to print a receipt. The 
printer director in one preferred embodiment is a collection of instances of related JAVA beans 
which operate to carry out printing activities, and is one of the directors among the terminal 
directors 144. The printer director includes a print class which is schematically shown separately 
which is operative to invoke a print URL method. The printer class in the preferred embodiment 
1 0 O includes access to the shared transaction data object which includes the customer specific 

information conceming the transaction that includes indicia representative of information to be 
printed. In the case of an automated banking machine this may include for example indicia 
S representative information which is read from a customer's card input to the machine and read by 
a card reader. This would include for example the customer's name and account number. The 
1 5 M= other transaction information may include the types of transactions conducted such as a deposit, 
;;f withdrawal or inquiry as well as the amoimt involved in each respective transaction. 

The transaction services application 146 receives the print request and passes the URL 
string to the WIN printer object 1 84 by the print URL method. The URL address in one 
preferred embodiment is the address of an HTTP record such as an HTML document that will be 
20 used to format the document to be printed, in this case a receipt. This HTML document contains 
the embedded JAVA script that processes transaction data from the transaction data object. The 
URL address of the document may be on a local machine or may be retrieved from another server 
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such as through a network schematically indicated 186. Network 186 may be a local area 
network or a wide area network depending on the configuration of the machine. 

The WIN printer object 1 84 next navigates to the address of the document to be accessed. 
This is done in the preferred embodiment using Microsoft's C Web Browser2 ActiveX control. 
When the HTML docxunent has been loaded the ActiveX control automatically begins processing 
the content of the accessed document. The transaction services application 146 invokes the print 
URL method of the WIN printer object 184. The WIN printer object uses the ActiveX control to 
print the current HTML document. This printing is processed by the Windows NT{g) print spool 
and graphics components. 

The JAVA CDI receives an event from the print monitor component 1 92 that indicates 
the completion of print spooling. This indicates that a file is now available to be read and sent to 
the common device interface (CDI) 188 of the receipt printer. 

Next a printer object 190 invokes a read data function in the print monitor 192 to 
determine the location and size of the print data file. The print object 190 sends the data or the 
path name of the data file to the printer CDI 188. The printer CDI 188 then passes the print data 
to the printer hardware. This results in printing of the document. 

Once the receipt is printed the applet from the printer director 1 82 issues a request to 
deliver the printed receipt. The delivery request is passed through the transaction services 
application 146 to the printer object 190. The printer object 190 invokes the deliver method on 
the printer CDI 1 88 to cause the receipt to be delivered to the user of the machine. The operation 
of the software components enables selectively accessing document formats as well as using 
instructions contained in the documents to include transaction data within the printed documents. 
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This enables producing documents of varied types. In addition it enables providing printing 
different types of documents for different customers. This may be desirable when providing 
marketing information, coupons or similar indicia on transaction receipts. This approach further 
simplifies providing printed formats in various languages by developing HTML documents 
which provide printed forms in different languages. In addition the methods of the present 
invention may be used for providing marketing to customers by profile or types of customer 
categories, as well as on a segment of one basis. 

While the printing method previously described is discussed in connection v^th 
delivering transaction receipts, similar methods may be invoked for the printing of statements for 
customers as well as for printing a transaction journal within the automated banking machine. 
Further by accessing selected documents controlling the format of printing the information 
journal records may be provided with consolidated information in a manner which enables 
conserving journal paper within the machine by not printing promotional or other types of 
information that is provided on customer documents. 

The printing method of the present invention also enables printing various types of optical 
indicia such as bar code or other types of machine readable indicia which can be used for printing 
coupons, checks or similar articles. Such coding may facilitate tracking the use of such items by 
customers for purposes of evaluating the effectiveness of various marketing efforts. In addition 
machine readable indicia may be used for printing on items such as deposit envelopes and/or in 
transaction journals. Such printing may facilitate reading such items by machine to verify the 
contents of deposits. 
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The printing capabilities achieved through the methods of the present invention also 
enables the printing of selected graphical materials. This may include for example materials 
which include imbedded digital signatures which can be used to verify the genuineness of the 
items printed. This may be particularly useful for example in situations where the transaction 
machine is used to print scrip, travelers checks, betting slips or other items having independent 
value. In addition printed documents in full color may be produced by including a color printer 
in the transaction machine. 

Computer software used in operating the automated transaction machines of the present 
invention and connected computers may be loaded from articles of various types into the 
respective computers. Such computer software may be included on and loaded from one or more 
articles such as diskettes or compact disks. Such software may also be included on articles such 
as hard disk drives, tapes or ready only memory devices. Other articles which include data 
representative of the instructions for operating computers in the manner described herein are 
suitable for use in achieving operation of transaction machines and systems in accordance with 
embodiments of the present invention. 

The exemplary embodiments of the automated banking machines and systems described 
herein have been described with reference to particular software components and features. Other 
embodiments of the invention may include other or different software components which provide 
similar functionality. 

Thus the new automated banking machine and system of the present invention achieves 
the above stated objectives, eliminates difficulties encountered in the use of prior devices and 
systems, solves problems and attains the desirable results described herein. 
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In the foregoing description certain terms have been used for brevity, clarity and 
understanding. Hov^ever no unnecessary limitations are to be implied therefrom because such 
terms are for descriptive purposes and are intended to be broadly construed. Moreover the 
descriptions and illustrations herein are by way of examples and the invention is not limited to 
the details shown and described. 

In the following claims any feature described as a means for performing a function shall 
be construed as encompassing any means capable of performing the recited function and shall not 
be deemed limited to the particular means shovra in the foregoing description or mere 
equivalents thereof. 

Having described the features, discoveries and principles of the invention, the manner in 
which it is constructed and operated and the advantages and useful results attained; the new and 
useful structures, devices, elements, arrangements, parts, combinations, systems, equipment, 
operations, methods, processes and relationships are set forth in the appended claims. 
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CLAIMS 

We claim: 

1 . Apparatus comprising: 

an automated transaction machine including: 

a computer, the computer in operative connection with a memory; 

an input device in operative connection with the computer, wherein the input 
device is operative to accept user inputs; 

a sheet dispenser in operative connection with the computer, wherein the sheet 
dispenser is operative to dispense sheets; 

software executable in the computer, wherein the software includes a first object 
operative to control the input device, and a second object which is operative to 
control the sheet dispenser, wherein the computer is operative to access at least 
one HTTP address, wherein transaction device instructions are accessible at the 
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address, and wherein the first object operates the input device and the second 
object operates the sheet dispenser responsive to the instructions, and wherein the 
software fiirther includes a transaction data object, wherein the transaction data 
object is in operative connection with the first object and second object and is 
operative to store therein data representative of both user inputs to the input 
device and the dispense of sheets by the dispenser. 

2. The apparatus according to claim 1 wherein the software includes a browser and 
wherein the computer is operative to access the address through the browser. 

3. The apparatus according to claim 2 wherein at least one transaction device 
instruction is included in an HTML document. 

4. The apparatus according to claim 1 wherein the input device includes a card 
reader, and wherein the transaction data object includes data representative of card data read by 
the card reader. 

5. The apparatus according to claim 1 wherein the software further includes a third 
object in operative connection with the transaction data object, and wherein the third object is 
operative to access the data in the transaction data object. 



80 



6. The apparatus according to claim 5 wherein the machine further includes a printer, 
and wherein the third program is operative to control the printer, and wherein the third object is 
operative to cause the printer to print data corresponding to data stored in the transaction data 
object. 

7. The apparatus according to claim 1 and further comprising at least one HTTP 
server, wherein the HTTP address corresponds to the server, wherein a plurality of transaction 
device instructions are accessible through the server, wherein first instructions are accessible at a 
first address and second instructions are accessible at a second address and wherein the computer 
is operative to access the first instructions at the first address and the first object is operative to 
control the input device responsive to the first instructions, and wherein the computer is 
operative to access the second instructions at the second address and the second object is 
operative to control the sheet dispenser responsive to the second instructions. 

8. The apparatus according to claim 7 wherein the software further comprises a 
browser, and wherein the computer is operative to access the first and second instructions 
through the browser. 

9. The apparatus according to claim 1 and further comprising a back office 
processing system in operative connection with the computer, and wherein the software is 
operative to communicate at least a portion of the data stored in the transaction data object to the 
back office processing system. 
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10. The apparatus according to claim 1 wherein the transaction device instructions 
include an applet. 

11. A method comprising the steps of: 

(a) operating a first device in an automated transaction machine responsive to 
first device operating instructions accessed by a computer in the machine at a first 
HTTP address; 

(b) generating first data with the first device, responsive to operation of the 
first device; and 

(c) storing the first data in a transaction data object in a memory in operative 
connection with the computer. 

12. The method according to claim 1 1 wherein the first device is a sheet dispenser and 
the first data is representative of a dispense of at least one sheet by the sheet dispenser. 

13. The method accordmg to claim 1 1 and further comprising the steps of: 

(d) operating a second device in the machine responsive to second device 
operating instructions accessed by the computer at a second HTTP address; 
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(e) generating second data with the second device, responsive to operation of 
the second device; and 

(f) storing the second data in the transaction data object. 

13. The method according to claim 13 wherein the first device includes a card reader 
and the second device includes a keyboard, and wherein the first data includes data 
representative of card data read from a card and the second data includes data representative of 
an input to the keyboard. 

15. The method according to claim 1 1 and further comprising the steps of: 

(d) accessing the data included in the transaction data object with a software 
object operative in the computer; and 

(e) controlling a second device in the machine with the computer responsive 
to the object and the data in the transaction data object. 

16. The method according to claim 15 wherein in step (e) the second device includes 
a printer, and wherein in step (e) the printer is operative to print indicia corresponding to data in 
the transaction data object. 
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17. The method according to claim 1 1 wherein the computer includes a browser and 
wherein step (a) comprises accessing the first address with the browser. 

18. A method comprising the steps of: 

(a) accepting identifying data jfrom a user of an automated banking machine; 

(b) storing data corresponding to the identifying data in a transaction data 
object in software operating in a first computer in operative connection with the 
machine; 

(c) conducting a first transaction responsive to a user input to the machine, 
wherein conducting the first transaction includes accessing the data in the 
transaction data object. 

19. The method according to claim 18 wherein step (c) includes operating a first 
transaction function device in the machine, and further comprising the step of: 

(d) storing data corresponding to operation of the transaction function device 
in the transaction data object. 

20. The method according to claim 18 and further comprising the step of: 
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(d) conducting a second transaction responsive to a user input to the machine, 
wherein conducting the second transaction includes accessing the data in the 
transaction data object. 

21 . The method according to claim 18 and further comprising the step of: 

(d) accounting for the first transaction by the user, including passing the 
transaction data object from the first computer. 

22. The method according to claim 1 8 and further comprising the step of: 

(d) producing a printed record corresponding to the first transaction with the 
machine, including accessing the data in the transaction data object and producing 
indicia in the printed record corresponding to at least a portion of the data stored 
in the transaction data object. 
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ABSTRACT 



An automated banking machine (12) is operative to conduct transactions in response to 
HTML documents and TCP/IP messages exchanged with a local computer system (14) through 
an intranet (16), as well as in response to messages exchanged with foreign servers (20, 22, 24, 
26, 28, 96) in a wide area network (1 8). The banking machine includes a computer (34) having 
an HTML document handling portion (76, 80, 82). The HTML document handling portion is 
operative to communicate through a proxy server (88), with a home HTTP server (90) in the 
intranet or the foreign servers in the wide area network. The computer further includes a device 
application portion (84) which interfaces with the HTML document handling portion and 
dispatches messages to operate devices (36) in the automated banking machine. The devices 
include a sheet dispenser mechanism (42) which dispenses currency as well as other transaction 
devices. The device application portion communicates with a device interfacing software portion 
(64) in the banking machine through a device server (92) in the intranet. The device server 
maintains local control over the devices in the banking machine including the sheet dispenser. 
The banking machine operates to read indicia on the user's card corresponding to a system 
address. The computer is operative to connect the banking machine to the home or foreign server 
corresponding to the system address, which connected server operates the banking machine until 
the completion of transactions by the user. 
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